The document discusses the different levels of planning in Agile development: release planning, iteration planning, and task planning. It provides details on each level, including who is involved, how to define a release plan, estimating velocity, common problems and solutions, and examples. The key aspects covered are the differences between releases and iterations, estimating at each level, and breaking down stories into tasks.
These horizons are not set in stone, but we believe them to be typical of most Agile projects. Scrum, for example, tends to combine Release and Iteration plans into Sprint Planning.
Release planning can happen more often than, even per Iteration.
Ideally most of the defining, priorities and estimating has been done before Release Planning.
Velocity – estimating units per iteration
The significance of technical risks is that risky stories should be done earlier to mitigate potential issues
Release dates are often based on external constraints and can’t be moved
Setting iteration lengths is not a hard science and is largely based on the team’s prior experiences and comfort level and the size of the project
It is important to remember that the Release Plan is not set in stone and will change from Iteration to Iteration as business priorities change
A rebuild should involve both the Developers and Customers and prior to the rebuild the current Release Plan and Story backlog should be reviews and/or updated
It may be difficult to split a small story; on the other hand, small stories should be less prone to blowing up or external dependencies
The story representing what is not done can be deferred to a later Iteration based on Priority
You can use an application like Jira or Mingle that sorts the cards into iterations for you, or a simple table produced using Word or Excel also works – whatever tool you choose doesn’t matter
Optimizing Velocity never works because predicting the future is so unreliable – even if you add more team members you won’t necessarily go faster right away
Task planning as part of Iteration planning is usually a Scrum thing, but at Intelliware we prefer to task Stories when we’re ready to open them
Iteration and Task planning at same time is an all-day effort – Iteration Planning in the morning with the Customer, then the team assembles separately in the afternoon to do Tasking
Note that Agile teams do not Pair Program 100% of the time. More mundane or straightforward tasks may be picked up by individuals to be completed, whereas core production code or tasks involving design work should ideally be done by Pairs.
The above story and task list are both purely fictional
Sometimes Architects or Team Leads will assign specific tasks to developers or pairs for certain reasons, but this is still done in the context of the team as opposed to being assigned by external forces.
Not all Stories blow up during Tasking – ideally, some should end up smaller than originally estimated
The key thing is to watch out for system issues – if every Story blows up at Tasking then this could be an indication of an estimating bias or error that will need to get fixed
Task tracking during development is too complicated to get into here
Track the time spent on each Task vs. the Task Estimate and the total time spent on the Story vs. Story Estimate
Compare these numbers vs. a rough idea of the % Complete to get a preliminary idea of where the story is going in terms of overall status