In this fourth and final article on agile estimation and planning we’ll look at planning. Part 1 and Part 2 of this series we looked at how relative estimation could help us improve our estimation accuracy. In Part 3 we looked at how team-based estimation further helped us further develop a comprehensive view of the problem being estimated. Combining the approaches of relative and team-based estimation we are able to improve the accuracy of our estimates, however since we’re not estimating in units of relative effort instead of time the question of how we can use this information to perform planning arises. This article addresses this outstanding issue.
A key question is how, if we are using relative effort instead of time, can we actually produce a plan. The answer comes from a couple of characteristics that are common to several agile approaches including Scrum. Using the Scrum framework, we develop product increments in short-term fixed-duration periods of time that we refer to as sprints. A sprint is typically one, two, three, or four weeks in duration. Once we select the sprint duration for a project, this duration remains constant. Another characteristic of our work is that we prefer to use teams that are stable and focused, i.e. not multitasking across multiple projects. The combination of fixed-duration sprint and a stable team results in our being able to very accurately understand how much effort can be performed in a sprint. In fact, we can say that Scrum actually tells us, based on our history, how much effort we can perform, so instead of estimating in a traditional sense; that is guessing how long it might take to do something, we can actually use our performance history to accurately forecast what we can commit to in a sprint.
We often refer to this as velocity, but we can also think of it as the teams capacity to perform work. This concept is simple, but powerful. It also allows us to start working at work a bit differently than we have traditionally, allowing us to make some other optimizations to our approach to delivery to help our clients improve their business results. More on this in a future post.
One way that I often describe this when I’m training is we can think of the sprint as a bucket.
Like a bucket, a sprint has a finite, predictable capacity. Particularly after we’ve run a few sprints, this capacity is well understood. Prior to being well understood, however, we can use historical information from previous projects to provide reasonably accurate forecasts of the number of sprints (buckets) that will be required to perform a given scope of work. Knowing what we have completed — those things that are truly done and delivered for use by our client — we can calculate our velocity, and knowing the velocity and having estimated the work we are planning on performing, we are able to provide estimates of how many sprints it will take to complete a given scope of work. Knowing how many sprints, and given the nature of sprints being fixed-duration and fixed-team, we can also accurately forecast the cost of a given scope of work.
The following graphic depicts a very simple project plan given an estimated product backlog and a known velocity.
Of course we’re still estimating, so this isn’t precise, but in our experience we can be quite accurate in our planning and forecasting.
I’ll leave this series with a final image, a burndown chart from a recent project where these techniques were applied. While it would be misleading and inaccurate to say that the results depicted are always this good our experience indicates that the agile estimation and planning approach can provide very accurate planning and tracking. We would encourage others to try these techniques and see if they might work for your organization. We also invite feedback and discussion around this topic.
