Agile Planning - Reality vs. Fantasy
Applying Principles from The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson
In traditional project management approaches a project plan is developed at the beginning of the project. It is based on very little concrete information about what needs to be built, the technolgoy that is going to be used to build it, and the productivity of the team. Based on all of that uncertainity, product owners and stakeholders will still want and specific day when the project will be delivered. This is a fantasy. Actually it is closer to a drug induced hallucination. With so much that is unknown it is impossible to predict a date (month, day, and year) when the product will be delivered. It is even uncertain if a month or quarter can be predicted with so little information.
This is where Agile planning steps in. It acknowledges at the beginning the size of the work is a relative sizing against all the work to be done for this particular project. So one project can not be measured against another project. We can set an end date for when we would like the release and we can even identify what the velocity needs to be to meet that date. But that is not our plan. Those are our ideal conditions.
What happens next is we engage in our sprint (iteration) process and decide how many stories we can accomplish within our sprint. The stories that are finished, meaning they are coded, unit tested and QA tested, count towards the velocity for this particular sprint. The total velocity for a sprint is total number of story points completed within a sprint.
Those story points are removed from the backlog and we now have a product burndown.
Once we have three sprints we can predict, based on an average velocity, how many sprints it will take to complete all of the story points in the backlog.
And here is where the hard work begins for the product owner. If it is going to take longer to finish all the work than the time allocated the product owner will have to choose. Will they choose to reduce the scope so that enough work to meet the date. Or will they move the date out. The average velocity may improve over time but it should not be counted on to happen for planning purposes.
The Agile Planning model is based on the realities of knowing something about the work that is being done (we have a few sprints worth of work completed), we are using the technology to build the product, and we now know what the team's productivity currently is. Each sprint will adjust each of these factors which will again force the product owner to make choices earlier in the project lifecycle rather than at the end of the project where it is often too late to do anything except go into project management death march mode.