How does a Sprint work?

What is a Sprint?

The main purpose of a sprint is to deliver working software or service. In later sprints you can add or develop existing functionality to the working software or software. If there is no working software or service yet it is next to impossible for a product owner to decide whether the software meets the requirements from the product backlog.

This implies that a sprint is one timeboxed iteration of a continuous development cycle. This time of should never be longer than a month and preferably be shorter than a month. Within a sprint, planned amount of work has to be completed by the team and made ready for review. This requires a lot of discipline, focus, collaboration and creativity. To facilitate this scrum has a lot of artifacts to help the organization to reach their sprint goals. You can adjust the way these artifacts to fit your organizations needs, as long as you keep the principles, goals (working software) and responsibilities the same as in the agile manifesto and the scrum guidebook.

Let’s take a look at the sprint process and it’s artefacts. When I mention working software, this also means working service or product.

The Sprint process

Step 1: Making a product backlog

Your first step in the Sprint process is the Sprint preparation. This step is about making a product backlog.

The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product.  Typically, a Scrum team and its product owner begin by writing down everything they can think of for working software. These items need to be prioritized. The product backlog will never be set in stone and will keep on moving.

A typical Scrum backlog comprises the following different types of items:

  1. Features
  2. Bugs
  3. Technical work
  4. Knowledge acquisition

By far, the predominant way for a scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, “As a customer I can go to my personal portal and see how much money I have saved by buying a different brand of insurance.” By making the functionality this specific, there will be less miscommunication and it will be easier to estimate how much work it will be. Please be aware that add-ons to a user story are usually new user stories. When people read a user story like the one in our example, they will think of new functionality that is easy to establish alongside the original user story. When you allow these add-ons to the original story, it will become harder to deliver the story in one sprint. It will also make the story more complicated and prone to defects and surprises along the way.

Because there’s really no difference between a bug and a new feature — each describes something different that a user wants — bugs are also put on the scrum product backlog. This implies that not all bugs are solved immediately after discovery.

Technical work and knowledge acquisition activities also belong on the scrum backlog. An example of technical work would be, “Upgrade all … to a new version of….” An example of knowledge acquisition could be a Scrum backlog item about researching various tools and knowledge which can help you to perform better during the sprint. These two are often forgotten, leading to them not being performed or leading to sprint deliveries taking more time. Sprint is about helping your development team reach their goals, by reducing stress from unpredictable requirements and unexpected rush jobs. Anything that add unpredictability should be put on the backlog.

Step 2: Planning the sprint

Once the product backlog is prioritized and the high priority items have their user stories it is time to start working on the sprint planning. This is done in a sprint planning session with the product owner, the scrum master and the development team.

During the sprint planning session the development team determines which items they can complete during the upcoming sprint. The team then moves items from the product backlog to the sprint backlog. In doing so, they transform each product backlog item into one or more sprint backlog tasks so they can more effectively share work during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted (definition of done). The definition of done and the user stories will keep on getting clearer during the sprint. Before the sprint starts there should be a shared understanding of what the user stories and the definition of done mean.

The development team starts at the top of the prioritized sprint backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five. This is done to get the most out of the sprint.

How long a sprint planning takes is dependent on how long your sprint will take.  In a sprint of 4 weeks, the sprint planning should not take up more than 8 hours. It takes practice to really get sprint planning done right. Do not be to though on yourselves when you do not succeed the first couple of times. And always make sure to learn from the previous sprints and sprint plannings. Your scrum master can help with this learning process.

Step 3: Developing the product (the Sprint)

The duration of a sprint is determined by the scrum master. The scrum master is the facilitator and manager of the scrum framework. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same.

After a sprint begins, the product owner must step back and let the development team do their work. During the sprint, the development team holds daily stand-up meetings to discuss progress and brainstorm solutions to challenges. The product owner can and should join t(some of) the daily stand ups, but he is not in charge and just there to help clarify items if needed.

The daily stand-up meetings are about

  • Planning the next 24 hours
  • Sharing successes of the previous 24 hours
  • Mitigation of risks caused by obstacles

Most team’s work with kanban or other visual tools to monitor sprint progress.

Only the scrum master or product owner has the power to interrupt or stop the sprint.

The length of the Sprint artefacts depends on the length of the Sprint

StepSprintSprint planningDaily scrumSprint reviewSprint retrospective
Lead time with 4 week sprint4 weeks8 hours15 minutes4 hours3 hours
Lead time with 2 week sprint2 weeks4 hours15 minutes2 hours1.5 hours

Step 4: Reviewing the delivered product (Sprint review)

At the end of the sprint, the team presents its completed work to the product owner. The product owner uses the definition of done established at the sprint planning meeting to either accept or reject the work.

The backlog is altered to reflect the delivery of this product. Typically the product is presented to the product owner and other stake holders during the sprint review. The length of the sprint review depends on the length of the sprint.

Step 5: Reviewing the Sprint (Sprint retrospective)

During the sprint retrospective you look at the way you conducted your sprint to look for things that went well and things to improve upon. You look at

  • People/collaboration
  • Processes
  • Tools
  • Sprint artefacts

Each of these discussions can lead to new to new items on the product backlog. The scrum master facilitates this meeting.


Add Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.