I don't believe in IPMs

I like celebrating on successes, whether it is making a test pass, finishing a task on a story or finishing the story itself. I also love celebrating what we have achieved in an iteration. If we complete 15 story points in one iteration – Great . If we completed 20 points in the last iteration, well it was still great – we added 15 points worth of value to the application.

It is because of this love of celebrating successes that I really hate signing up to delivering a certain amount of points or certain stories at the start of an iteration (commonly in IPMs). 

I have heard the reasons for signing up to what you deliver in the iteration including having a clear goal about what will be achieved that week; knowing how many stories we think we can cover so that the BAs can plan and define the stories for the next iteration; and you won’t know how fast you can go if you don’t say how many points you will achieve. I have counter-arguments to these (of course).

The first: having a clear goal about what will be achieved in that iteration. If you don’t sign up to stories, how will you know what goal you are working towards? Easy – we are working on the current release. Our goal for the iteration is actually to complete as many stories for the release that we can achieve. The business can still prioritize top stories, so we know which stories we should deliver first, but our actual goal of the iteration is to work through as many stories in the backlog as possible. 

The second: knowing how many stories we think we can cover so that the BAs can plan and define the stories for the next iteration. If you have a look at how I would run a IPM-less project, you can see that the BA will always have know when they need to start defining the next lot of stories, governed by how full the bucket is.

The third: You don’t know how fast you can go if you don’t say how many points you will achieve. Agh, my favorite argument, worthy of its own post. I will just touch briefly on it. Sometimes, people say “last iteration we said we would complete 20 stories, but we only completed 17 stories. This week, lets say we will achieve 20 stories again so we can improve on last iterations effort”. That is all very well, but this is just an arbitrary number. Without the goal of completing 20 points, I could say “so far in this iteration, we have achieved 12 points. We have 2 more days left – hey if we work well then we can beat that this iteration”. Knowing how fast you can go is only relevant when working out when the release will be deliverable, and this can always be done with yesterday’s weather.

How would I do it?

At the beginning of the release, you have a backlog of the stories for the release with estimates on them, so you can gauge how long you think the release will take to complete (there is no difference here). Then, you identify which stories are the most risky to play (which will deliver value) and ones which have to be played first and you prioritize the top 10 (at this stage this is just an arbitrary number, depending on the number of pairs you have). You then have a bucket which holds top 5 (again, arbitrary) stories.

• When a developer picks up a new story they have to pick up something from the bucket, but what they pick up is their choice – first in first served basis. 
• Any bugs which arise are added to the bucket (assuming the business wants to fix them). 
• No new stories can be added to the bucket until it is empty.    
• The business has the power to replace a story in the bucket if they feel something else will deliver better value.
• When the bucket is starting to look empty, the BA can then define the next lot of stories, taken from the original top 10 which will go into the bucket.
• 5 new stories get added to the prioritized list so that we still have a Top 10.

Working in this manner has many advantages:

1.  Developers can be incentivized to completing their story quickly because they want to their pick of the stories in the bucket (if they took a long time, then a great story could disappear)
2. The team is self-organizing as the developers decide which story they want to pick up first, in much the same manner as QAs self organize.
3. You only define the stories which will go into the bucket; you don’t waste your time defining stories for an IPM which will get thrown out because the developers didn’t feel like they could work on them.
4. You cut down on one meeting (the IPM).
5. Increases team morale as you celebrate what you achieved instead of morning what you didn’t deliver.
6. You plan your release date using yesterday’s weather, instead of yesterday’s weather and an arbitrary forecast.

I would still hold weekly showcases, where you celebrate all that you achieved that week and weekly retrospectives, where you can talk about what will make us go faster.

I still believe in iterations: just not IPMs.