How to become an Agile team

Part 3 — The Sprint

Part 2 of this article was all about getting your team, tools and work lined up so that you’re ready to start Sprinting. This final section covers steps 5–9 from the below and is all about what happens when you actually start sprinting!

Step 5 — Feature planning with the PO

Sprint Planning part 1 — Official ceremony no.1

All team members need to be there for the kick off Planning session. This is where you get under the skin of the problem with the Product Owner. The PO needs to be prepared and really understand their active role in the Sprint. Remember you’re doing this with them, not for them. Questions to cover in the planning session include; What are they trying to achieve? What output are they expecting? What’s their measure of success? Answering these questions makes sure everyone’s on the same page.

You need to define what the Sprint Goal is — what’s the point and/or expectation of the Sprint. You can then start bucketing the work up into ‘Features’. A Feature could be the physical outputs they’re expecting to see at the end of the Sprint (e.g. An animation on Energy Management) or merely a high level indication of the direction of travel ( e.g. I want to know some digital time saving hacks). We’ve had lots of learning with Features; either too high level, too granular, too vague, too meaningless. It’s an ongoing learning curve. Each Feature gets its own card in the ‘Features list’ on the Trello Sprint board.

The PO should then prioritise these Features on the board. Highest at the top. The team may decide that it’s not all achievable in the Sprint duration. You can agree there and then to take some off, or see how you go in Planning part 2 (see step 6).

(We’ve got some newer thinking on Planning which now includes a Research and discovery feature or phase. Check out our Iterative Insights update)

Lastly you agree contact terms with the PO, making sure they’re available as required.

Step 6 — Task planning with the team

Sprint Planning part 2 — the nitty gritty

The team now goes through the Features at a granular level to work out the solution. What tasks do they need to complete to make sure the Features are done at the end of the Sprint. This may involve a number of task cards with checklists per feature. Trello’s useful here as you can tie cards together with coloured labels to see what’s related. It can be tempting to skip this stage and go straight to doing work. This is certainly going to be true if you have a team who tend to see planning as dull and boring. We have learnt the hard way here as well and the Scrum Master needs to hold firm on guiding the team to do this stage. (Again, we’ve got some newer thinking on Task planning, check out our Iterative Insights update)

It’s now that the team can realistically see how much work there is in the Sprint, and therefore whether it’s achievable.

If a Feature needs to come out, that’s where the PO is called back in to sense-check the order and agree what stays in and what gets cut, or de-prioritised.

The team also needs to agree on how they’re going to run the Trello board. What is the definition of ‘Done’? If a card hit’s this column, then it’s all reviewed and signed off with the team and PO. Finito. Likewise, the team needs to understand what the ‘Review’ column means — is that a review with the PO, or a review by the team? It’s best to clear these up from the outset, rather than revisit them continually in the Retrospectives.

Then you Sprint.

Each team member picks a task card they want to do from the board. Moves it to the ‘In progress’ list and assigns themselves to it. Sometimes people pair up to join skillsets, get it done faster, or learn something new. It’s up to them. This is where the self-organising team part of Agile clicks in, and the Scrum Master aims to give people the space to get the work done.

During the Sprint, the team will most likely need some input from ‘non-sprinters’ who may not have any Agile experience. They probably won’t get that the timescales are pretty much instant, and that everything is riding on their answers. Therefore, we’ve learned to warm them up at the start of the sprint, and get some provisional time penciled in with them. Chasing people right at the end of a sprint, given they’ve only just been contacted, is not cool. We’ve also spoken about having a brief ‘elevator pitch’ ready for the non-sprinters so they get the gist of the sprint and more importantly the timescales!

Step 7 — Standing up when sitting down

15-mins-a-day keeps procrastination at bay — Official ceremony no.2

Same time. Same place. Same format. We do our daily Standups via Hangouts, and use the Trello board tasks as our reference point. We learned from our Agile colleagues in Tech and have our Standups before 10 am. For us, the purpose is to confirm what people are working on that day, to highlight any issues blocking them, and to identify if anything has changed which affects priorities or ‘Done’ tasks. We specifically don’t cover what people worked on the previous day as this is usually covered in the previous Standup, or can be seen on the board. The team also gave the clear feedback that they thought we were wasting time discussing the past! The PO is invited to join the Standups (it’s a recurring meeting in Outlook for us), but this isn’t a must.

The Standup isn’t a problem-solving forum but a progress check in. If solution-mode creeps in, then this needs to be called out and pushed out until after the Standup with the necessary people (“take it offline”). This makes sure you aren’t wasting time! This is easier said than done and an issue which often creeps back in, given the team’s inclination to help each other. The Scrum Master can step in and help keep the Standup focused.

Standups have produced something quite extraordinary in our team. The daily video team contact, initially perceived as a chore by the team (“what do you mean every day!”), is now missed when it’s not there! It’s created a real bonding experience for a team that doesn’t sit together. Who’d have thought it? I’m not sure it would have been so successful as a standard (Skype) conference can’t-see-everyone call.

Step 8 — The no-surprise Showcase

The big taa-daaaaa! or is it? — Official ceremony no.3

For us, this is really a contextual ceremony. No two Showcases have been the same. A Showcase signifies the end of the work on the Sprint and is the point the team has been sprinting towards. We usually keep it between 30 and 60 mins. Along the way, we have learned to really tailor our Showcase to our audience. If you have stakeholders attending, then you may need to show them the outputs and do a real jazz-hands experience. However, if it’s your PO and they’ve seen the outputs along the way, then it can be whatever the PO would like to see to essentially sign off the Sprint as Done. We’ve had Showcases that were big reveals, and we’ve had others that were discussions based on the already seen outputs. We’re even debating whether the name ‘Showcase’ is right for us, and might rename it to suit.

The value in the Showcase is that it acts as a hard close. It’s also a chance for some much needed recognition for the team on the completed work. The Showcase slot provides the pressure to keep up momentum in the Sprint, and a very real time-bound goal to aim for. Without this formal element, there seems to be no official close to the work.

However, on the flip side there’s also a danger that the sheer momentum to move every task to ‘Done’ in time for the Showcase can end up sacrificing quality, and therefore the very definition of ‘Done’! We’ve fallen into this trap on quite a few occasions. The trick it seems is to be really strict on the definition of ‘Done’. It’s better that only a few priorities are truly at 100% than everything at 80%ish — and therefore actually unfinished!

Step 9 — Retro and repeat

There’s nothing old-school about Retros — Official ceremony no.4

The purpose of the Retrospective is to focus on incremental improvement for the next Sprint. What can you learn from the Sprint that you either need to amplify because it was awesome, or work on because it wasn’t? This is a chance for open and honest feedback between the team. And it works.

We run the Retro almost straight after the Showcase, but have found you should separate the two — even if only by 15 mins — to allow people to clear their heads.

Again, we use the Hangout and Trello combo. We use a brand new board for Retros, with four lists: Last Retro actions, What went really well, What could have made this Sprint even better, and Actions to take forward. Typically, Retros last for about an hour and kick off with a fun game or icebreaker. There are loads of Retro games online. We made up a rock/paper/scissors alternative using the effects in google hangouts — Hats beat Beards, Beards beat Glasses, Glasses beat Hats J

We usually give people 5–10 mins to individually create the cards in the ‘Went well’ and ‘Get better lists’. Trello updates in real time so cards appear to everyone as soon as they are added. The Scrum Master then starts grouping these into themes. It’s then over to the team to talk through the themes and discuss what’s been called out, and why. The aim is to air any issues, call out the great stuff, and agree on anything to work on in the next Sprint.

It’s a slow burn initially, but after a few Sprints people start opening up and there are some very real gains to be had by having the discussion. It’s usually an eclectic mix of process improvements through to feelings and attitudes. We pull through the agreed actions to the next Sprint board so they’re visible throughout that Sprint. At the start of the next Retrospective we run through how it went putting them into action, and whether they are still issues to carry forward and work on. This loop seems to work well.

And then….

You turn your attention to the Backlog and start setting up the next Sprint planning meeting.

It’s truly relentless, but the team’s work, and the team-work, is all the better for it!