Planning in Agile varies a lot given the kind of project, the size of the team, the dependencies and commitments to stakeholders. Because of this, Agilists around the world hold varied opinions on how much one should plan in an Agile project.
There is no prescriptive answer to that question, however, the level of detail one can go to before putting together a project plan can be decided based on the given circumstances.
Minimal planning is working out of a prioritized backlog of stories
Prioritizing stories based on business value is almost always the first step in plannning. Once we have a prioritized product backlog the team can start working on the highest priority story from the top of the stack.This mode of working is particularly useful when there are no strict timeline commitments for the stories to be released to production. This might happen in scenarios where it is a small application and the product owner is comfortable with doing a release when he feels that enough is built in the application to be seen by the users. This can also happen when the team is working on enhancements or bugs post a production release, and is waiting for business to decide the next milestone. This works well in small teams of 2-3 pairs.
Planning a Single Sprint
The next level of detail is planning atleast for a Sprint(2-4 weeks). A Sprint backlog (or an Iteration Plan) helps in creating visbility for a very limited period of time which is useful both for the Product Owner as well as the team. An example of a Sprint commitment to a product owner can be delivering 20 points of work from the product backlog which translated to 5-6 User Stories.
Planning only for one Sprint is useful when the Product Owner does not have longer term visibility on features/stories for the team. This might also happen when we are waiting things like user feedback etc... to determine the next set of stories to be played.
Doing Release Planning across Sprints
A longer term view of the feature pipeline can help the team build an exhaustive release plan across Sprints. This can be done by slotting stories in an Iteration and even looking at paralellization of stories between development pairs. This sort of activity is best done by sticking stories putting up all the stories on a release wall and collaboratively building the release plan on it.
The number of stories slotted within an iteration is guided by the velocity the team thinks it can achieve. This release plan gives a planned burn down of the scope which the team sets out to achieve and acts as a great metric for the team to measure "How are we doing ? "
Doing Release Planning for multiple work streams in a program of work
Doing a release plan for multiple workstreams in a program is extremely helpful to identify dependencies across streams. It also helps rollup a program level burn up across all teams in the entire program of work. This is particularly useful when running a large program with multiple work streams where tracking progress and dependencies on a day to day basis becomes difficult. Doing a little more of upfront planning helps in the long run.
The assumption of a fully prioritised backlog is one of the things which distinguishes SCRUM from many other agile approaches. Particularly at the start of a project, your "Minimal" planning stage can also be too heavyweight.
ReplyDeleteFor example, I worked on a project which actively solicited stories from a range of stakeholders. At the start of the first iteration, there were over 100 candidate stories from five or six widely distributed stakeholders. Despite trying a variety of approaches, we soon found that getting any kind of consistent overall priority could take days for each story. Development was being held up while we waited for prioritisation. And I won't even get into the delays caused by attempting to estimate the whole backlog.
To cut through this barrier we took a more Kanban-like approach and simply asked each stakeholder for their single most important story, and began work on those. As we neared the end of a story we asked for the next most important and so on.
In absolute planning terms this may not have produced an optimal ordering of stories. Some stakeholders may carry more weight than others, or some stories may bring in unexpected pre-requisites, for example. But at least we were able to start work and deliver something to get that vital early feedback.
@Frank
ReplyDeleteYou make a perfectly valid point. Sorry when I meant a prioritized product backlog I did not mean the entire set is prioritized before development starts. The act of getting priorities is iterative and everyone learns in the process, even the stakeholders.
The first approach with minimal planning most often works in the situation you describe. As long as you have a story or two to feed the development capacity work should begin. When stakeholders see the working software , things slowly start getting aligned.