Back to Blog

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

Matt Turrell, May 22, 2017

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:

Flat burndown chart

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.