Moving Towards Being Agile – Planning

Agile Planning – User level

Release planning for a product is like taking a road trip with young children. You know when you’re starting your journey, you know where you have to get to, but you cannot know what nappy accidents you will have along the way. You don’t know where you’ll get to each day, or how long it’ll take, or whether you’ll hit a roadblock or diversion, but you do know that each day you will make progress in the right direction (unless you get lost, which could also happen… especially if requirements aren’t defined well). Along the way, you make the finer decisions as you learn more about the domain (like taking petrol breaks and bathroom breaks at the same time!), and you can learn from your mistakes. There is no need to decide which petrol station you’re going to hit in 3 days’ time and what time you’ll fill the tank, much as there’s no need to define what you’re going to use to persist your data six weeks in advance. We may be able to take a detour to see the mountains and waterfall if we have time, but this is definitely a “nice to have” and if we don’t have the time then we won’t do that. Crucially, we won’t know at the outset whether or not we will have the time. Not knowing every detail of your work is *fine*, that’s the beauty of being Agile.

In order to plan your backlog, you need to determine your product owner (singular), who is the ONLY person who can determine the priority of your backlog. You should split your overall feature into bitesize chunks that can be completed in around 2-3 days, and these are your user stories (more on these later)

When it comes to requirements, our product owner should know the order that s/he wants the requirements implemented, Saying “everything is high priority” gets us nowhere, because we aren’t going to implement everything at once. Ask them to be brutal, make sure the backlog is properly ordered so that we have a clear to do list cut out for us.

It can be difficult for users to define requirements or determine value of different features. Below are some ideas that they can use to make the task slightly easier. They can be used independently or in a combination of some/all of them to try and get our backlog created and prioritised.

To get initial requirements, get all stakeholders/users/product owner into a room, and give them some cards/post-it notes and a pen. Bear in mind here, that users aren’t only business users of the application, but also (e.g.) those people who will be supporting the app (like production services for example). Also, very importantly, no one is allowed to speak or communicate in any way other than writing throughout. Give them a fixed time (<10 minutes) to write everything they want the application to do. Next, ask them, again in silence, to stick the post-it notes on the wall. This is your backlog. Finally, group the duplicates together – which goes some way in determining the value of each story – the more people who want something implemented, the more important it is overall that it does get implemented. Also, by making the entire exercise silent, it gives everyone a voice, even those who wouldn’t usually speak up.

Another method of determining value is to again ask your clients/product owner/any stakeholders to sit in a room and give them each an amount of virtual money (use monopoly money if it’ll make them happier). They need to allocate an amount to each story from their own pot of money based on how much they want that particular story – and hey presto! we have a prioritised backlog. Furthermore, if there are any stories which have no money against them, they clearly aren’t wanted or needed by anyone, so we can scrap them :). The drawback of this method is that we are writing stories for the ENTIRE backlog and asking them to prioritise way into the future, so maybe this method can be adapted to prioritise each feature rather than each granular story.

User Story Mapping
Some product owners/stakeholders find it difficult to give absolute priority to one story over another much as a parent would find it difficult to choose one child over another. However, in the same way that a parent would know which child to choose in a particular context (e.g. which child to take to the next football game, which child to buy a Barbie doll for), a stakeholder is able to choose stories based on particular themes, or areas of the project.

Split your backlog into themes, and write out stories for each theme. Ask your stakeholders to decide the top 2-3 items from each theme and accept that into your next sprint. Each sprint, go back to the user and ask them for the next priorities for each theme. If you find you can’t accept all of these stories into the next sprint, then ask the user to prioritise between the top priorities for each theme – there should only be a handful of stories to choose from here.

We should only really have the next two to three sprints of work planned out and prioritised at any one time – this gives scope for change later down the line but means that there is clear direction at least for the foreseeable future. We need 2 sprints at least so that if a sprint goes well and we have spare capacity, we know what the next story to bring in is. Once this is done, we don’t care what is next until these stories move along to make space for new ones – at this point in time, priority 20 and priority 200 don’t matter to us. We will not even dare to mention their names until we accept them into our backlog (i.e. the next 2 sprints).

REMEMBER: Users should be doing all this. Developers should not be the ones prioritising the work!!!

Agile Planning – Developer level

You should now have a prioritised backlog at least for the next 2 sprints. You first task is to refine the story. This means, firstly, that the WHOLE team should understand the business need for the story, the scope of the story, the acceptance criteria (i.e. exactly what will be delivered with this story), the technical touch points and implications for the story. Once it has been refined, ask the product owner to review the acceptance criteria and accept that that is what s/he would like from that particular story.

Next, discuss the story in your teams, and come up with an estimate for how complicated the story is. To do this, we use story points instead of time estimation – it is difficult to estimate time/absolute estimation, but we can compare very well. We pick a benchmark story, give this a score, and compare the stories we have against this to give them a relative points score. Story points traditionally follow the Fibonacci sequence (1, 2, 3, 5, 8, 13, …). The Fibonacci sequence is useful here because the larger a number gets for a story, the less important the increments become. For example, suppose we simply went up in even 2s (2, 4, 6, 8, 10, 12, …). If we know a story is complex, how easy is it to differentiate between a 10 and a 12? Is there any value in giving something 10 points instead of 12? Similarly, the difference between 2 and 4 is quite big – if you have two relatively simple changes, but one was slightly more complex than another how would you reflect this on your scale?

Whilst the goal of allocating story points is not to provide a time estimation, everyone does the conversion in their heads! Here is a suggested conversion from Phil, but note that it is just that – a suggestion. Use whatever works for you.

  • 1 – 1/2 day
  • 2 – 1 day
  • 3 – 3-4 days
  • 5 – 5 days
  • 8 – 10 days

If something is more than an 8, it means it’s probably too big and needs to be split further. Even an 8 is risky – if anything goes slightly off plan then you blow the sprint so proceed with caution! Ideally, your stories will be a few days to a week, nothing more.

Once this is done, the story is ready for development. Pick this up, and work on the story together until it fulfils all the acceptance criteria. When developing in an Agile way, techniques such as TDD/BDD (Behaviour driven development) and pair programming are ideal, but these are not subjects for this post.

When planning for the day, or the week, or the sprint, we need to move away from “scope boxing” to “time boxing”. Basically, instead of saying “this story is finished when xyz is done” we say “we will work for x hours on this story. Whatever doesn’t get done will be moved into a separate one.” Meetings should also be time-boxed or you’ll find yourself talking more about the work than actually doing it. If a meeting is going to overrun, stop and reschedule for another time. People’s concentration drops otherwise, and you achieve nothing in the extra time anyway.

Some argue we should get rid of sprints altogether. Why work to an arbitrary notion of a sprint? Work continuously, demo once a story is finished and just keep going. What happens if you work in sprints is that you either tend to run over, and stay late on a Friday to finish what you said you would, or you plan less work than you feel you have capacity for so that you don’t get yourself into that situation.

When planning, focus on the big rocks – those things that we can’t release without. As time allows, move on and look at the “nice to haves”. Work together with the users to ensure that the things that are being worked on ARE the things that they want in there.

Agile Retrospectives

One form of Agile uses Retrospectives for developers to talk to one another and see what is going well, what’s going badly, what they’d like to change etc. Some argue, why wait until the end of the sprint? If you see a problem, you highlight it and change immediately. Retrospectives are still good in case there’s stuff you forget, or just to give some structure. As with anything agile, if it works for you, keep it. If not, find something that does.

One suggestion from Phil Japikse(@skimedic) is the “Start, Stop, Continue” method. Take 3 different coloured post-it notes, each person writes what they’d like to start doing to improve things, what they want to stop doing because it’s not working out well, and what they like and want to continue doing. Share this with the team, remove duplication and see what themes recur across team members. The things that fell under “Continue” would be stuck up on the wall so that the team don’t forget to keep doing them. Importantly, only take on one thing to start at a time, taking on too much will mean that nothing actually lasts.

NB, only Pigs should be invited to the Retrospective, not Chickens.

Next up: more about stories.

<<<< Moving Towards Being Agile – Documentation

>>>>Moving Towards Being Agile – Stories


2 thoughts on “Moving Towards Being Agile – Planning

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s