Scrum teams have several ways to track project status. One is that at the end of the Sprint, the team must have potentially shippable code. Having teams give demonstrations to the Product Owner of the new features at the end of each Sprint is a great way to encourage this goal. At the end of the Sprint, the software is potentially ready to be shipped or not. This kind of binary status, common in agile development processes, tends to be more meaningful to Product Owners than the perennial "we are 85% complete."
|Figure 4. Ideal Sprint Burndown Chart: In an ideal Sprint, the burndown chart shows steady progress.|
Another way Scrum teams can measure progress is with burndown charts. These are charts in which the amount of work left to be done in a Sprint is updated on a daily basis and made available to the entire team. If at the beginning of the Sprint there are 200 hours of work to be done, on day 2 the chart is updated to indicate how much work (as estimated by the developers working on each task) is still left.
As tasks are completed—coded and tested—the number of hours left to be done decreases. When no tasks are completed, the number of hours left to be done stays the same from one day to another. Figure 4 shows an example of a Sprint burndown chart in which everything went perfectly. Every day of the Sprint the team completed 20 hours and finished everything on time.
|Figure 5. Troubled Burndown Chart: This Sprint burndown chart shows a Sprint where things did not go as planned.|
On the other hand, Figure 5
shows an example in which the team ran into some difficulties on day 3 (the number of hours left remained almost the same as the day before) and these difficulties continued on days 4 and 5. Perhaps some of the items were harder to implement than the team had anticipated, or a teammate got sick.
Whatever the reason for the slowdown, by day 6 the team had taken some corrective actions (for example, removed a few items from the Sprint after talking to the Product Owner) so they could provide potentially shippable code on the items still achievable by the end of the Sprint.
Scrum is not a silver bullet. Even when using Scrum it is still possible (and likely) that things will go differently from what was planned every now and then. However, with frequent inspection and adaptation, the team detects these variations as soon as they happen, and adapts to its new environment. This ability to quickly adapt to a new environment is one of the key differences between empirical process controls (like Scrum) and defined process controls like the one used by traditional non-agile software development processes.
Perhaps the best tracking mechanism that takes place in Scrum teams is the constant feedback loop that Scrum provides. By having the entire team (Product Owner, developers, quality assurance, and ScrumMaster) collaborating throughout the duration of the Sprint, teams tend to know more about where they are, notice if they are falling behind, and act to solve such problems on a regular basis.
Getting Started with Scrum
At its core, Scrum is extremely simple; some might even say that it is just plain common sense. However, if you have never managed a project with Scrum, I recommend that you start small. As with most process change initiatives, success depends on people truly embracing the new paradigm. The ScrumMaster coaching role during the initial stages is crucial for teams who want to adopt Scrum and succeed with it. See the Scrum Resources sidebar for some good resources.
Scrum works very well with collocated teams of 5 to 10 members including the Product Owner, developers, quality assurance, analysts, and the ScrumMaster. You can scale it up to work with larger and distributed teams but I suggest that you start with a small collocated team.
Likewise, if you are using six-month iterations in your current development process, perhaps the concept of two-week Sprints would be too much of a shock for your organization. In that case, you might start with 30-day Sprints, see how those work for your team for a while, and then decide whether you need to do shorter iterations.
Scrum provides a framework for cross-functional self-organized teams to work together towards a common goal. The principles of visible progress and constant inspection provide transparency to teams and allow them to quickly adapt to changes in the environment. In today's fast-paced world of new technologies, changing requirements, and increased pressure to get to market, Scrum's practices can help you deliver working software, with the right features, more often to your customers.