Who says there’s no planning in Agile?

As Agile software development becomes increasingly popular there’s still a common misconception that it requires no planning. And yet a study undertaken by VersionOne discovered that 30% of respondents are actually worried about Agile’s lack of up-front planning.

I believe this fear stems from a basic misunderstanding of either:

• What Agile actually entails, or
• The Agile Manifesto.

For instance, in the Agile Manifesto many people read, “Responding to change over following a plan” to mean absolutely no planning is needed (1). However, the entire Agile Manifesto is also underpinned by the mantra: “That is, while there is value in the items on the right, we value the items on the left more.”  

Now – I don’t know about you – but I don’t think this implies Agile needs no planning. It just means planning is not the primary focus.

Many have already debunked this ‘no planning’ myth, so I’d like to focus more on the practical side of things. For instance, how do you actually plan in Agile? And how do you plan upfront?

There are already multiple planning workshops involved in Agile, including Project Inception/ Initiation/ Kickoff, Release Planning, Iteration Planning and Daily Standup. So, for the purposes of this blog, I’ll focus on one of the most important and upfront planning exercises: Project Inception. I’ll use my own experience to explain what can be covered and go through how some of the critical exercises work in practice. Along the way, hopefully I can pass on a few key lessons I’ve learned.

What do you cover in a Project Inception?

As the name suggests, a Project Inception is held at the start of every project. It’s a series of workshops designed to identify:

• What your project is
• Why you are doing it
• What tasks you need to complete
• When you believe the project will be completed.

You can go through a number of different activities to achieve answers to these questions, including (but not limited to):

• Assessing your goal and vision
• Problem statements
• Scope (in/ out / unsure)
• Personas & product box
• Stakeholder analysis
• Project tradeoff sliders
• Technical design discussion
• Story card identification
• Estimation
• Prioritisation
• Iteration planning
• Release planning

I always use problem statements to understand the purpose of a project, scope and story card identification to determine what is and isn’t being delivered, and prioritisation to decide what should be worked on first.

However, you could treat each of these bullet points as a workshop in itself – within the Project Inception series of workshops they’re normally run back-to-back. Remember, it’s important to understand exactly what you’re trying to achieve at a high level before selecting which workshops are applicable to your project (for specific details on each step, check out references 6 & 7 below). 

Why these specific activities?

Going through your problem statement, scope, story card identification and prioritisations at a Project Inception helps you plan what to work on and in which order.

Once you’ve completed these activities, you can pretty much leave the room and start development work – particularly appropriate in an environment where time and cost aren’t primary project constraints.

However, sometimes these constraints are important to your stakeholders, in which case estimation, iteration planning, and release planning become critical to your Project Inception. So, in the next few sections, I’ll explain further how these essential activities work.

What problem are we solving?

When kicking off a project it’s important to understand what problem you’re solving first (e.g. what’s the point of putting in all this effort?).

A problem statement is one way to do this. It will help you understand:

• Your problem (describe a single problem and identify what is the root cause of the problem)
• Who’s affected by it (is it impacting your team, the company, your customers etc.)?
• The problem’s impact (best described using tangible impacts – e.g. loss of 20% traffic for the last 6 months)
• What a successful outcome would look like (remember, the outcome is not a solution, as you haven’t yet discussed your project’s scope).

It will probably take a few revisions for your team to develop a concise and clear problem statement. Don’t worry if you need to define multiple statements, it’s important at the outset to acknowledge if there is more than one problem to solve. You can also ask each member of your team to write down their own problem statements then bring everyone together to agree on overarching statements.

Once you’re comfortable with your project problem statement/s it’s time to move on to scope.

What’s in Scope for your project?

Like any good project plan, it’s vital to identify what scope you’re going to include, what will be excluded and elements your team is currently unsure about. This delivers extra clarity about your project focus at a high level.

A scope identification exercise I use is to draw up three columns on a whiteboard (like the example below) and get the team to brainstorm what they believe is in, out, and unsure for the project.

Then as a team we review and debate whether each item is appropriately placed (the product owner has the final say on any functionality if we can’t come to a consensus). Once we have agreement, we identify people to confirm the unsure scope items at a later date.

By completing this scope identification we can then determine what needs to be done at a lower level. These become our story cards.

How do you break scope identification into story cards?

For this next stage, I like to run a group exercise to involve everyone in writing up the project’s story cards. I’ll divide the team into smaller groups to take on a few scope items, attempting to write their story cards using the story card format:

• As an <a type of user>
• I want <some goal>
• So that <some reason>

The team will then vet each group’s story cards to ensure they follow the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable). I’ll normally rotate the groups around so they get to look at all the scope items and identify if any story cards are missing based on what the team currently understands about the project.

Once you’ve identified all your story cards, it’s vital to understand which you should focus on first and what cards will be included in the initial project release. This is similar to the “scope in, out, unsure” stage, but it gives each story card an order of priority.

In Agile its common to prioritise using the MoSCoW approach (what is a Must have, a Should have, a Could have, and Won’t have). Generally the product owner will provide the explanation for why each story card falls into which priority. You should go through this activity until you’re completely comfortable with the order of priority and have identified what’s required for initial release.

As I mentioned above, sometimes time and costs are important to your stakeholders. By identifying which story cards will form your first release you can use the below approach to come up with an estimated release date.

So time and cost are important to you… How can you understand more?

Estimation iteration planning and release planning exercises produce a forecast of when your team believes they will hit key project milestones. These are agreed releases based on how you prioritised your story cards.

To go through these exercises you’ll need to follow a number of steps (illustrated below):

1. Estimate all required story cards using planning poker, relative sizing or whatever technique works best for your team. The estimates will need to equate to a number (i.e. 1, 2, 3, 5, 8, etc.)
2. Determine how many story cards your team thinks it can achieve in an iteration. Total up the number of story points. Repeat this process 4 times (or until you feel comfortable), and continue to total up the number of story points for each attempt
3. Expected velocity for an iteration. Average the 4 attempts to determine how many story points the team believes they can achieve in an Iteration. Confirm again whether the team believes this is realistic
4. Establish how many story points you require for first release. Divide the total number of story points for the first release by the expected velocity for iterations. The output will tell you how many iterations the team expects it will take to finish all the story cards for the first release.
5. Apply the same equation to further releases. Note you will need to re-evaluate them after the first release based on actual velocity.

Completed all the essential activities explained above?

Hurray! You’ve finished project inception and created the basics of your Agile project plan. Now you can start project development.

As you can see, all this planning can be completed upfront and is very much part of Agile – so I hope you consider the “no planning in Agile” myth thoroughly debunked and have picked up some practical tips on how to run your next Project Inception successfully along the way.

I’ve only covered a few of the Agile workshops in the Project Inception stage – there’s still lots more to discover!  If you’re interested in more information, please feel free to check out some of the references below. And, if you have any thoughts or some great tips for others, don’t forget to leave a comment.

References:

1. Agile Manifesto 2001, viewed 12 February 2014
2. The Agile Inception Deck, Rasmusson, J  2010, viewed 13 February 2014
3. Advantages of the “As a user, I want” user story template, Cohn, M 2008, Mountain Goat Software, viewed 11 April 2014