Thursday, March 11, 2010

The 10 Commandments of Agile Planning

Agile planning is a subject that can cause a disproportionate amount of noise, frustration and misunderstanding across agile projects and programmes, departments and companies.

Let's start at the beginning by quoting part of the Agile Manifesto:
"...through this work we have come to value: ...Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more."
So, first of all there is value in following a plan, but we value responding to change more.

The problem we are dealing with exists at a deeply engrained cultural and organisational level, and that is corporate governance. Most corporations run on an annual planning basis steming from accounting and investment cycles. Quarterly updates are expected against this plan and any deviation from this forecast (whether positive or negative) has an immediate impact on the share price, investor confidence and ultimately the well-being of the company.

This fundamentally means that costs are planned on an annual basis, portfolios of work are planned on an annual basis, and therefore resources are budgeted and assigned on an annual basis. So... How can an iterative process be planned for!

If your company works in this matter, you either have to change that process (not for this blog), or adapt, and provide a project roadmap/ longer-term plan/estimate. The problem we all face is that no matter how many caveats and assumptions we provide with this forward looking view, expectations will become set as milestones because the rest of the business needs to plan marketing, budgeting, resource allocation activities etc off the back of the software you are producing. "When will it be ready!"

So, unless you can change the entire company, you have to provide a long-term estimate.
But HOW you produce that estimate IS in your power.

The 10 Commandments of Agile Planning

Commandment 1: Thou Shalt Create the EPIC
Create the EPIC with the sponsor - get them to write it or at least review and verbally say yes this is kind of what we're after.
Write a user story that encapsulates what the person paying the bill wants. e.g
As the person on the line for this software and paying the bill,
I want lots of good software,
So that... things improve in certain areas,
And the value to the company... is that we make lots of money.
The Acceptance Criteria is that there are lots of ticks in lots of boxes.
For more info on User Stories: http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development

Commandment 2: Thou Shalt Make the Plan a Backlog Item
Write a user story to create a Project Roadmap with associated value defined and acceptance criteria.

Commandment 3: Thou Shalt Timebox the Planning Activity
Discuss with the sponsor how important a long-term view is and whether it is the highest priority item on the backlog, and ask them how much time/money they want to spend on completing the plan. Once the time/money is agreed calculate/set the timebox.

Commandment 4: Thou Shalt Go Forth and Communicate
Recognising that this is an estimated guess and working hard on the communication of this fact is a critical activity... It is an opportunity to educate your peers, sponsors and stakeholders in the nature of software development and the difficulties of trying to predict a non-predictive process.
Once you start this communication, ensure that you promise to update the long-term view on a regular basis e.g. every release or every sprint - I'd suggest at least every 6 weeks depending on sprint/release length.
Agile development is an iterative process, and therefore the roadmap will be iterative and regularly updated. You can also talk about the ability for the business to change it's mind as it goes and talk about velocity and how it is grounded in actual performance.

Commandment 5: Thou Shalt Engage the Entire Team
Involve every team member in the process. This will help to ensure everyone understands WHY they are doing the work, HOW the product backlog has been prioritised, and WHERE they fit in making it happen. Encourage the team to challenge each other throughout the process - what's the minimum required to achieve the business objective? Is that the best fit of solution? Is this really a high priority? Is the acceptance criteria clearly understood?

Commandment 6: Thou Shalt Iterate Throughout the Process
Have you ever been in those planning sessions where you've booked a room away from it all, and the entire team goes through the backlog trying to assign story points. And the points get bigger as you go because less is known, and the issues and assumptions list becomes as big as your arm? Take a chunk at a time. Divide the backlog into buckets of stories in priority order and ask the teams to take on stories for estimation, then close the meeting and allow time for the teams to go away and investigate and properly assess the work.
This way they can collaborate, challenge and communicate about the backlog and priorities and find out more about those assumptions and issues. Then meet again and take on the next bucket of stories until all stories required to meet the acceptance criteria of the EPIC have been looked at.

Commandment 7: Know Thy Backlog
The Product Backlog is probably one of the most, if not the most, important artifact to enable a project to provide business value. Ensure adequate resources are supporting the Product Owner to be able to articulate the stories, prioritise the stories and define acceptance criteria. Reviewing and updating the backlog becomes part of the planning process and there is no reason why all team members can't get involved in this activity.

Commandment 8: Thou Shalt Say How Big It Is
Separate the estimation process into 3 parts:
Firstly, how big is this story?
Secondly, how long will it take?
Thirdly, when will it be done?
To define how big the story is use Story Points. In relative terms, how big are each of the stories. Discuss and agree with the team a points systems e.g. fibonacci. Then agree a range ie. 1, 2, 3, 5, 8, 13, 21, and agree the largest points "allowed" on the backlog. Part of the process is to break down larger stories so that they fit the agreed scale.

Commandment 9: Thou Shalt Say How Long It Will Take
So this is the crunch part where everyone gets very uncomfortable, because to be honest no one knows. So why spend too much time on it? I like the sampling approach.
Each team, once they've sized (story pointed) their stories, takes a small, medium and large story. They should be stories that the team has a high level of "confidence" or "knowledge of" or are "comfortable" with.
For these 3 stories, go into a task identification and estimation process and task out everything required to complete these stories. Adjust point sizes and debate within the teams until the team recognises or identifies a ratio of number of points : number of days estimate.
This ratio is then applied across all stories regardless of the level of knowledge.
From this sampling applied across an entire backlog, the "when will it be done" can be extrapolated as a "numbers game".

Commandment 10: Thou Shalt Repeat This Process Regularly
Depending on your sprint and release length, repeat this process regularly as required by your sponsor. At the end of each release, use the actual velocity of story points burnt down in the release to update the roadmap to provide an indicator of how effectively the team is achieving the roadmap. Hopefully, you will only need to create a roadmap once for an EPIC, and then normal release planning can resume and the roadmap updated based on velocity as an admin/numbers task.

Summary
No one who is experienced in software development and agile development in particular, wants to try to predict a non-predictive process. But... Until companies change their governance structures to match the planning period of release cycles (unlikely for most people), longer-term agile planning will be required.
But, by using these commandments I think you'll benefit from the following:
1. Transparency with sponsor on scope and acceptance criteria of project.
2. Transparency with sponsor on the cost and time taken to provide the plan.
3. Buy in from the team because it's the highest priority item on the backlog and the sponsor wants it and is willing to pay for it!
4. A better product backlog by the end of the process.
5. A joint understanding across the team of why the project exists, and what the business expectations are.
6. Open communication channels with sponsor and stakeholders.
7. Expectation of updated roadmap on frequent basis, based on actual velocity being achieved.
8. A consistent means of measuring velocity.

2 comments:

Ian Shimmings said...

Though it gets the shortest paragraph, I think Commandment 2, create a Project Roadmap story on the backlog was the key thing to do. It changed the perception of the roadmap from being another unnecessary project artefact that adds little value and gets in the way, into a customer deliverable just like any other piece of functionality. It also helped get the idea past the teams Agile police!

I have used a similar technique in my early days of Agile to solve the “Scrum doesn’t allow for documentation but the customer insists” dilemma. Treat it like any other requirement - give it an estimate, put it on the backlog and the customer will prioritise it with everything else.

Most of the rest of the Commandments seem to say that, given the customer has prioritised the roadmap to the top of the pile: first mitigate the risks by helping management understand it is just the start of the planning progress; and second, if we have to do it, let’s make sure the team gets the most value out of it.

A good blog post. And since we are currently working on the same project where we have just completed such an exercise, I can confirm it really can work!

Fabrice Talbot said...

Fun post Steve! I'm a big fan of your 5th commandment "Thou shall involve your whole team". The sooner we make changes in the product, the better.

I wrote a similar post on agile businesses myself http://blog.agilewords.com/2010/04/is-your-business-agile/