Getting stories to 'Done' faster: Using retrospectives and team principles to boost teamwork and accelerate delivery

A project I’ve worked on recently has had a recurring problem of flat burndown charts, with sprints feeling like they were becoming mini-waterfalls.

Here’s an example:

This isn’t good as you have no value delivered through the sprint, sign-off is back loaded to the end of the sprint which increases the risk of missing the sprint commitment, bugs are found and (hopefully) fixed later on and there’s little visibility through the sprint of what will actually be achieved. To name but a few.

There were always good reasons for this happening, but we were still experiencing the problem after a number of sprints.

After a particularly challenging sprint, I decided to change the approach for the retrospective, to hopefully empower the team to take control of this.

In the days running up to the retrospective, I asked the team in Slack to think of a way to answer the following question and send it to me as a private message, “How can we … ?”.

At the start of the retro, I put all the suggested questions on the wall and asked the team to dot vote on the one they would most like to address.

Overwhelmingly the team voted for “How can we get stories to 'Done' faster?”.

What resulted was a constructive hour-long conversation about a wide variety of principles we could try in the coming sprint to help us achieve this goal.

As a result of this, the next sprint’s burndown chart was much healthier:

The chart’s not perfect, of course, but it showed a clear change in the right direction.

In the following retrospective, I put all the principles we’d agreed to live by in the previous sprint on index cards on the wall and asked the team to rate themselves on each one, on a scale of one to ten with post-its (naturally).

This highlighted principles we needed to discuss and to refine, for the coming sprint.

We followed the same process in the next retrospective, by which point the ratings were much higher and the principles had become integral to the way the team was working.

Since doing these exercises, I’ve had the privilege of listening to some of the best team collaboration conversations of my career, with the team totally motivated to deliver their sprint commitment.

These are the principles the team arrived at (I’ll expand on some of them in future posts):

1. Strict Work In Progress (WIP) limit of 4 Product Backlog Items (covering 'In Progress' to 'Done')
   

2. Everyone is responsible for picking up pull requests (PRs)
   

3. If it's your PR, you complete it
   

4. Don't check-in on a broken release
   

5. Until the release is green, don't start another task
   

6. Ensure early sight of stories with PO (Product Owner) / Testers / UX|Design (ideally before PRs)
   

7. The developer reviewing the PR must see the acceptance criteria applicable to that PR being met, before it can complete
   

8. Stand-up format: prioritised story based rather than person/activity based (priority numbers in card headings)
   

9. Only testers can move the cards into test
   

10. Descriptions on all PRs
    

11. When implementing a story, if we start to deviate from the way we said we'd do it in planning, hold a team conversation
    

12. Add implementation notes to stories during planning (if appropriate)
    

13. When implementing stories, consider whether any documentation is required
    

14. Pair in the team when making fundamental changes
    

15. In planning, prioritise the biggest/riskiest stories to be tackled first
    

16. Team conversation as soon as there is a red release
    

17. If there's a release/environment issue and it's your CI Build or PR, pair up with someone in the team who knows about environments/release pipeline
    

18. When writing tests, pragmatically consider their performance
    

19. All Devs sanity test using IE not Chrome
    

20. Nominate a person in planning to write the implementation notes (tasks) for each story (if required)
    

21. Small PRs
    

22. Pragmatically decide branching strategy on a story by story basis (e.g. task based or other)
    

23. Disable items not ready to be used to prevent blocking the pipeline
    

24. Use 'WAIT FOR' in tests rather than 'THREAD SLEEP'
    

25. Self-organisation
    

26. Only the PO can set priorities
    

Of course, there are always challenges delivering sprints. That’s one of the reasons we’re here. Constantly looking at the way the team is working, trying and testing new approaches will help those challenges become much more manageable.

It’s easy to fall into the trap of doing the same retrospective format each sprint. It’s worth keeping an eye on this, that one hour slot every two weeks can be used to make a massive positive impact on the team and on delivery.