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):
Strict Work In Progress (WIP) limit of 4 Product Backlog Items (covering ‘In Progress’ to ‘Done’)
Everyone is responsible for picking up pull requests (PRs)
If it’s your PR, you complete it
Don’t check-in on a broken release
Until the release is green, don’t start another task
Ensure early sight of stories with PO (Product Owner) / Testers / UX|Design (ideally before PRs)
The developer reviewing the PR must see the acceptance criteria applicable to that PR being met, before it can complete
Stand-up format: prioritised story based rather than person/activity based (priority numbers in card headings)
Only testers can move the cards into test
Descriptions on all PRs
When implementing a story, if we start to deviate from the way we said we’d do it in planning, hold a team conversation
Add implementation notes to stories during planning (if appropriate)
When implementing stories, consider whether any documentation is required
Pair in the team when making fundamental changes
In planning, prioritise the biggest/riskiest stories to be tackled first
Team conversation as soon as there is a red release
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
When writing tests, pragmatically consider their performance
All Devs sanity test using IE not Chrome
Nominate a person in planning to write the implementation notes (tasks) for each story (if required)
Pragmatically decide branching strategy on a story by story basis (e.g. task based or other)
Disable items not ready to be used to prevent blocking the pipeline
Use ‘WAIT FOR’ in tests rather than ‘THREAD SLEEP’
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.