Given that Agile is an iterative and incremental process, it should come as no surprise that there are different levels of Agile planning to help deliver value early while working toward a larger goal. To find success with Agile, it’s important to understand how to effectively plan at the release, iteration, story, and task levels.
What you’ll learn in this presentation:
• The basics of release and iteration planning.
• The differences between a release and an iteration.
• The basics of task planning.
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