All about Agile

On The Inside: Fail to plan and you plan to fail

Welcome back to On The Inside! This is part 5 of my Agile adventure at Allthings, a technology startup in sunny Dundee building a group project collaboration tool. If you haven’t read part 1 (which is all about diving into the deep-end!) then you can find it here (you can read last weeks here). I’m trying to give an honest, personal, warts-and-all account of our journey…

There is nothing worse that getting halfway through a sprint only to have a seemingly simple story explode in your face. Hidden complexity in a story can create unexpected work and delay which can derail your sprint completely. If you’re going to minimize these surprises you need to have a good sprint planning meeting.

The sprint planning meeting is the regular meeting at the start of the sprint where the development team, coach, QA team, UX/UI designer and Product Owner meet together. In the meeting they discuss what everyone is going to achieve during the next sprint. Having all those people in a room can be a real pressure point in your sprint cycle. It’s expensive, takes up valuable time and if not executed properly can drag on endlessly without giving any valuable answers.

So how can you avoid endless planning hell?

The key to a successful planning session is being prepared. Every meeting, not just planning sessions, cost a lot and it is essential to get the most out of the time you’re going to use. It’s important to know who you’re going to invite and what you want to achieve. After that, prepare as much as you can ahead of time.

Here are some tips that I’ve used to help my planning meetings:

1. Have a preplanning meeting with the TLs (Team Leaders) and the Product Manager. Use this hour to cover the stories with the TLs letting them sense check the new features. In my experience, they will quickly let you know about:

• What you’re missing

• Any user journeys you haven’t thought of

• Any technical issues

Getting these “what if” type questions early when there is time to go away and get answers before the planning meeting is incredibly useful. It can help get rid of the obvious problems early.

2. Prepare a definition of ‘ready to work on’ to help the Product Owner filter out stories that just aren’t ready to be started. It sets a bar for quality to the Product Owner of a story and can go a long way to preventing and discovering a missing feature or technical issue mid-sprint.

The preplanning can also highlight to the team where a spike is needed. I like to think of spikes as reconnaissance missions. They’re an opportunity to explore a technical or business issue and figure out how things work.

Don’t be tempted to keep spike code. Rewriting it after the knowledge has been gained by the team will take a fraction of the time and the quality will be much higher second time round.

What about the sprint planning meeting itself? What can you do to be prepared?

One thing is having more stories ready to be worked on than you can possibly complete in a sprint. If a story gets kicked out on a technicality you won’t be scrabbling around to find valuable work or forcing stories to be added when they’re not ready.

Make sure you have the tools you’ll need (digital or physical). Pens, post it notes, a room, whiteboard, projector or TV. Have whatever you think you’ll need.

Create an agenda and send it out beforehand. At the start of the meeting I like to write my agenda up on the board. I’ve used pie chart agendas for a while as it helps keep people focused on time. Here’s a link to Gamestorming for more info on pie chart agendas.

Here’s what I put in the agenda for my sprint planning meetings:

Sprint capacity planning

Have the TLs gather any holidays in the team and total the completed work from the previous sprint. This makes calculating the sprint capacity much easier and shows the team just what’s possible.

Story run through

Introduce each story in turn to the whole team. This is a quick walkthrough of all the stories to give the sprint shape. Any initial feedback can be captured for further discussion rather than delay the process.

Present any available prototype as a possibility, not the way it has to be. Discuss alternatives wherever you think the design is weak. This can help the team take ownership of the design and be more engaged with discussions.

Set a goal

Make sure you set with the team what the essential outcome of the sprint is. This helps prioritizing during the planning and throughout the sprint by assessing if any given piece of work is moving the team towards or away from the overall goal.

Break

Keeps everyone fresh but also lets all the information sink in.

Story breakdown

This is an Engineering and QA (Quality Assurance) task breakdown of each story. Ensure as the story is broken into pieces that each piece still follows the INVEST model, especially Valuable and Testable. QA can help a lot here by keeping everyone focused on how they are going to test each piece of the work as it is delivered, rather than wait for it all to arrive. This can make sure that the slices of a story are end-to-end useable and still delivering value.

Keep going until you’ve reached your capacity. Ask if anyone needs a break at the end of each story and make sure there are drinks and snacks available! Try to keep the energy in the room high.

Keep it light. Lots of diagrams. Whiteboard sketches. Pass the pen a lot. Encourage those who haven’t spoken for a while to contribute. Make sure everyone has a role to play in the meeting. Sometimes that’s taking notes. Sometimes it’s presenting to others. Sometimes it’s getting a round of drinks. Whatever, but try to keep everyone contributing.

Play planning poker. Estimation of pieces can be as simple as a show of 1 to 5 fingers. Estimation is a topic I’ll cover in another article…

Walk the sprint

When you have enough broken down stories I find it useful to walk through the whole sprint. Who is going to do what and when? This can highlight bottlenecks and coordination problems with the tasks and gives everyone a bigger picture perspective of the whole sprint. This is in no way set in stone and rarely works out exactly as planned during the walk through. That’s absolutely fine. It’s still valuable to know how the whole sprint hangs together.

Post planning clean up

Ask for concerns and make sure everyone believes that the sprint is achievable. Check the room. Is everyone signed up?

Make sure the stories are clear and everything has been captured properly. If you use a physical board then move the post-it notes to the board. If it’s electronic, check that everything is in the tool.

Now, take a deep breath. You’re done. Reflect on how it went and get ready for the sprint. The proof of the pudding is in the eating as they say. But don’t worry too much, you’ll have another opportunity to do it all again in a few weeks…

Are you enjoying this Agile series? Let me know! Tweet your views @allthings_io and sign up to get the latest from On The Inside. What problems are you facing?

This is part 4 of an ongoing series. Click on the links below If you would like to read previous episodes of On the Inside!