The 4 Parts of a Sprint in Agile

Since the beginning of civilization, sprinting has been one of man’s most prominent pursuits.  Being the fastest runner is an accomplishment worthy of praise and admiration.

This ultimate form of achievement has many parallels to project management, where progress and pursuit of an end goal is a daily focus.

The sprint is the basic building block of scrum, a framework of agile project management.  Unlike traditional project management where the full project is planned in advance, scrum projects are divided into iterations or cycles which are planned in detail.  Each of these cycles is called a sprint, and it has four basic parts:

1. Sprint Planning
2. Execution
3. The Sprint Review
4. Sprint Retrospective

Sprint Planning

To get the sprint started, a sprint planning meeting is held by the scrum team, which includes three participants:

1. The scrum master
2. The development team
3. The product owner

The main purpose of the sprint planning meeting is to determine what will be accomplished during the sprint.  More specifically, items are moved from the product backlog to the sprint backlog.  The sprint backlog is a prominently placed notice board such as a white board or a wall where sticky notes can be assembled.  Each product feature is placed on a kanban board which has four categories:

1. Not started
2. In progress
3. In testing
4. Complete

An estimate is produced for the sprint during the sprint planning meeting.  In the software development industry it is common to play estimation poker, a game in which each member of the development team chooses a number from the fibonacci sequence for each item in the sprint backlog.  The fibonacci sequence is where each number is the sum of the two before it:

• 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …

This acknowledges the lesser degree of accuracy the larger the work is.

Each member of the development team chooses a number from the fibonacci sequence for each sprint backlog item.  Thus, the estimate is not a dollar value, it is a number of story points that establishes the size of the item to the other items in the sprint backlog.

The number of story points accomplished in one sprint is tracked by the scrum master, and the the appropriate number of product backlog items can be inserted into the sprint.  However, the productivity of the team generally increases due to human factors and familiarity with the project, therefore the number of story points per sprint trends upwards throughout the project.

Execution

In a scrum project, several things happen during the sprint:

• Daily scrum
  Every morning, a meeting takes place between the scrum master and development team.  The third major scrum team member, the product owner, is optional.  This meeting is timeboxed to 15 minutes, in fact, many people run these meetings standing up (and call them stand-up meetings) in order to ensure they don’t turn into elaborate discussions.  The purpose of the meeting is to coordinate the team and communicate any impediments that are hindering productivity.  Each member of the scrum team answers three questions:
  • What did I accomplish yesterday?
  • What will I work on today?
  • What impediments are in my way to accomplish this?
• Burndown chart
  As described earlier, a number of sprint backlog items are identified during sprint planning and the goal is to complete them during the sprint.  Each item has been estimated and assigned a certain number of story points, thus there is a story point value for the entire sprint.  A burndown chart is a line chart that starts with the total number of story points to be developed during the sprint, and it gets updated throughout the sprint as the story points are completed.  Thus, it is a line chart that slowly dwindles to zero (hopefully) at the end of the sprint.
• Swarming
  Ideally, the entire development team works on one sprint backlog item at a time, that is, swarming the requirement.  This is not always possible nor the maximum efficiency, but it is applied as a general rule of thumb.  The opposite of swarming is trashing, when a developer moves quickly throughout many tasks.

What happens when the end of the sprint is approaching and the scrum master realizes there isn’t enough time to accomplish the story points within the sprint backlog?  In traditional project management, there are three options:

1. Fast track the schedule (perform tasks in parallel that were planned in sequence)
2. Crash the schedule (add more resources)
3. Change the scope of the project (remove tasks)

In scrum methodology, the answer is to move sprint backlog items back into the higher-level product backlog.  They will be accomplished in a future sprint.  During the sprint planning meeting for the next sprint, the scrum team will consider whether the priority of the item is high enough to include within it and continue on the item.

The decision to remove an item from the sprint must be made by the product owner.

The Sprint Review

The first of two meetings that happen at the end of the sprint is called the Sprint Review.  It is timeboxed to 1 hour per week of sprint, hence between 1 and 4 hours.

The responsibilities of each team member correspond to their work on the project.  The scrum master facilitates the meeting and ensures it stays focused.  The product owner reviews the sprint goals.  And the development team present fully functional software to the product owner.

The sprint review has three components:

1. Review of the sprint, including which items were completed and which were amended from their original form and why.  Discussions of project progress and what the sprint accomplished in relation to the overall project.
2. Presentation of completed and functional product.  Although the review and approval of the product should not happen during the sprint review meeting (it should be performed as it is completed, during the sprint) the sprint review meeting provides an opportunity to demonstrate the working product in its current form, after a series of new features have been developed.
3. Stakeholders can ask questions and provide feedback.

Formal slides or powerpoint presentations should be avoided during the sprint review meeting.  Rather, the focus should be on demonstrating working, functional products.

The Sprint Retrospective

Finally, the Sprint Retrospective meeting takes place at the end of the sprint (usually right after the sprint review meeting) and is attended by the scrum team.  It is timeboxed to 45 minutes per week of sprint.

The purpose of the sprint retrospective is to examine the team’s internal processes and suggest improvements.  Scrum team members assess what went well in the sprint that was just finished, and what can be improved.  It focuses on the people, processes, and tools that the scrum team uses.  The output of the sprint retrospective is a number of recommendations for improving the processes that are being used to deliver the project.

All scrum team members should give input into the sprint retrospective.  If one team member is silent or doesn’t care, the whole scrum process is subjugated and loses the collaborative benefits of agile project management.

The sprint retrospective represents the essence of agile.  The iterative nature of project management together with a regularly planned time of introspection and adaptation is what makes the methodology so powerful.

The sprint is what harnesses the power of human achievement into your projects, and strong project management utilizes it to the fullest.