Explaining agile estimating and planning is the hardest part when teaching a class.
That’s because people freak out when they hear about story points and relative estimations.
Why wouldn’t they?
If you’ve ever done a project before in your life, you know that at some point in time, you’ll need to tell your stakeholders when it’s going to be finished or how much it’s going to cost. If you then reply: “In agile projects, we don’t care about up-front estimations. The team plays planning poker before each iteration and measures velocity afterwards.” you’re bound to get some funny looks.
That’s natural, because you first have to explain agile release planning.
What is our goal in Agile software development?
- To avoid investing money & time in up-front work because we know the future is uncertain and things change.
How do we address this?
- We invest just-in-time, in focused time-boxes.
What is missing?
- If we do everything just-in-time, we’ll never be able to do release planning.
True, if we estimate iteration by iteration, we’ll only know our cost and release date at the last iteration.
You don’t have to be a veteran project manager to know that the only way to successfully deliver a project is to continuously monitor scope, budget and time. Depending on the primary project focus, you can work with the other constraints to keep it on track. (Don’t let people who say they successfully manage a project with 3 fixed constraints fool you, they actually do the same because they include contingency buffers.)
This also applies to agile projects. Even better, it’s much easier to monitor these constraints. After each iteration you’ll have new data.
- How many person-hours have we spent?
- How many story points were delivered?
- How are we doing on timing?
In order to be able to use this data, you need a fully estimated (release) backlog.
If you keep your releases small, it’s not difficult to split up the requirements to a user story level. Techniques such as user story mapping are a great way to do this.
The next thing to do is to estimate all user stories. But because you have limited detailed information at this point, the only thing you can do is compare them, thus estimating them relatively. This is where story points come in handy. However, stay away from planning poker! It tends to drag you into detailed discussions, which are not relevant at this moment in the project. A great alternative is silent grouping. The exercise on its own makes it clear to everyone involved that its goal is to get a first high level comparison, nothing more. Which are big user stories, which are small? Use story points as a scale, and you will have a fully estimated backlog. Quick and without much discussion. I still use planning poker, but only when we notice during iteration planning that a user story has a completely wrong story point estimate (which doesn’t happen a lot).
Skeptics might say : “How can this be accurate? You’re estimating without any detailed information?” True, some estimates might be high, others might be low. Some might level each other out. Whatever. Just remember, our goal is to get a first idea about the size of the backlog, nothing more.
A next step is to get an idea about the team velocity. If you can wait a few iteration, great! If not, guess! In both cases, you’ll have your measurements soon and you will need to adjust continuously. But at that point, you’re in control. Iteration after iteration you can project the results onto the release planning and adjust some of your constraints if necessary.
Take a look at this burn-up chart example as a tool to monitor the release planning of a project where timing was the main constraint. The worst case, best case and linear scenario make it visual that a plan is never going to be 100% certain.
If you think about it, agile projects are not that different. Letting go of the illusion of a fixed plan, drives a completely different behavior. One that focuses on creating value and making healthy decisions. The way project management was meant to be…