Your project kick off, you have the best team, the right technology, the perfect project plan (Gant Chart). For the first weeks, your project is running smoothly, but something change:
- Your lead developer accepts a new challenge in other company
- You realise the team is taking more time that what you have planned
- Your customer discovers what they really want
- The market conditions change
Agile planning is nothing more than measuring the speed a team can turn stories into working application and then figure out when the team will complete the application.
- We start with the master story list which contains a list of all the features our customers would like to see in their application.
- The speed at which the team turn stories into working features is called team velocity.
- Iteration is one to two-week sprints of work where the team turn user stories into working features.
To give us a rough idea about delivery dates, we do the following:
- number of iterations = total effort / estimated team velocity
- e.g. number of iterations = 100 points / 10 points per iteration = 10 iterations
Important: our first project plan is not a hard commitment. We do not know our team’s velocity and until we built something value and measure how long it takes, we won’t know how realistic our dates are.
Be flexible about scope:
Being flexible about project scope is how the agile team maintain the integrity of the plan.
Important: insist to customers to drop an old story every time a new one comes in. Also consider if the customer can’t drop and old story, we can push out the date. What customers can’t expect is to drop something in the list and not expect something of equal size to come off.
When it comes to pushing out the date or being flexible about the scope, the agile team prefer the latter. When you are pushing the date this is like saying you need more money.
Steps to create an Agile plan
- Step 1 Create your Master Story List: list of features prioritised by the customer and estimated by your team. A good master story will have about one to six months worth of work but no more
- Step 2 Define your Release: this is a logical grouping of stories that make sense to your customer, you want to choose the fewest number of features that deliver the most valuable in the first release (Minimal marketable feature set)
- Step 3 Size it up: the objective is to get a sense of how big the project is.
- Step 4 Prioritise: we have to get the most important first. Your customer will have the ultimate say about prioritisation, however, it’s the duty of the Agile team to make suggestions about what stories would be good candidates to build in the beginning to reduce architectural risks.
- Step 5 Team velocity estimation: in the beginning of the project, the velocity is going to fluctuate, but after 3 or 4 iterations, the velocity is going to settle down, and then you can get a better estimate of your team’s velocity. It’s also best to not be to aggressive in the initial estimate, be conservative, remind your stake holders that it’s a guess and start measuring from day one.
- Step 6 Pick the delivery dates: you can deliver by date or by feature set depending on what is more important the time to market or core set of features.
Important: delivering a feature means analysis, design, developing and testing.
Read the full series of articles about Agile Methodology: The Basics, Who and Why, How to Deliver, User Stories, Estimation and Planning.
Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf
8 thoughts on “Agile Methodology Planning”
Pingback: Agile Methodology Estimation | Carlose Lopez | Blog
Pingback: Agile Methodology User Stories | Carlose Lopez | Blog
Pingback: Agile Methodology How to Deliver | Carlose Lopez | Blog
Pingback: Agile Methodology The Who and Why | Carlose Lopez | Blog
Pingback: Agile Methodology The Basics | Carlose Lopez | Blog
Nice summary of an Agile methodology!
Thank you Chuck, I read great resources in your blog as well.
Pingback: How to move a slow project to Agile? | Carlose Lopez | Blog