RichardWhitehead

Richard Whiteheads' Blog

10 Ways To Improve Every Backlog

Every team I’ve worked with have approached their product backlog in different ways. It’s always surprising to see how much each team differentiates, when from the outside we should all follow a similar method right?

Over time every team, with experience, will work together to find out what works for them so there’s not a one-size fits all, but here’s some tips that can be picked up and applied to any backlog.

# Use user stories

The classic story format ‘As a …. I want to….. so that….’ has been tried and tested since the beginning of scrum. It’s the simplified but most effective way of capturing the value in a story by making it clear who the user is, what they want, and why they want it. I’ll be using this until I can find something better.

# Monitor the size of your backlog

Backlogs that contain 100s of stories become frustrating and painful to manage and it’s easy to loose site of everything that it contains. Is story 199 of 200 REALLY a priority for the product? It’s likely most of the stories at the bottom will remain at the bottom for a long time because by the time you get to them, something of more priority will have come up.

The tip here is: make sure you only have stories you need on the backlog – archive the rest. Backlog refinement sessions are a good time to do this. 

# Welcome the team to add to the backlog

My view is that anyone in a team team should be allowed to add to the product backlog but it is the Product Owner who chooses it’s priority. New ideas should be valued regardless of source; a developer may have discovered a more efficient way to do something or had an idea for an amazing new feature, but it would help the Product Owner by having a place, or a ‘tag’ on those stories which they can refer to during refinement.

# Keep it in priority order

This should be an obvious one. Your backlog should always been in priority order. This should be driven by the Product Owner but often needing input and guidance from the team.

When entering sprint planning the team should be able to pick the stories from the top of the backlog with confidence the Product Owner has already decided it’s highest priority for the sprint.

# Make it transparent

Everyone in the team should be able to see and have ready access the the backlog; Developers, Scrum Master and Product Owner. It’s valuable for everyone to see the vision for the product, what is likely to come up next and empower the team to contribute to that vision. I’ve seen too many times where the Product Owner doesn’t have access and someone manages the backlog on their behalf and am puzzled as to how this is possible.

# Regularly groom it

Backlogs are a living, breathing to-do list. The team should (driven by the Product Owner) often inspect the backlog and use the stories as talking points so everyone can really understand the Product Owners vision for that story. The team should also be able to relay back what are the dependencies,blockers, or ask questions before going into sprint planning.

# Estimate at a high level

In scrum we’re told to only really care about what’s in this sprint and a bit about what’s in next sprint. However business’s always want to know how much work there is roughly and how long roughly it will take.

We need a release plan. Each story should have a high level estimate of work so the Product Owner can relay to stakeholders when they may be able to use their shiny new feature.

This should be done as a team – not the Product Owner or a single developer.

If anyone wants to know exact delivery dates for something in the distant future, say ‘I don’t know, that’s not agile’

# Capture the detail

Every story should contain a user story, requirements to complete it (acceptance criteria), the definition of done and any other detail needed that will help deliver the story. It’s likely there has been some conversations about each story so write down the important parts from the conversation as we’re likely to forget when we come to work on it.

# Keep stories small

If you use planning poker or at least the Fibonacci number series to put an effort against a story, the higher the estimate, the less confidence we have in it.

Break down the stories until you are comfortable it can be delivered in the time you’ve estimated. Keep in mind that story still needs to deliver value.

# Most detail in prioritised stories

The backlog is in priority order and now it’s time to refine those stories. We should only refine stories looking 2-3 sprints ahead. Being agile, the priorities are likely to change. The higher priority the story, the more attention and detail it should get and this should gradually reduce as you move down the backlog.

Scrum Master Checklist

I often use to-do lists to keep track of tasks on paper rather than in my head. I have a Scrum Master checklist that I go through to help keep on top of a project, so I thought I would share this with my fellow Scrum Masters.

They’re all as important as each other so not really in priority order and are subject to change as we learn more.

  1. Are there any immediate blockers that need to be resolved?
  2. What are the highest risks and what can I do to minimize them?
  3. Is anything distracting my team from the sprint?
  4. Are my team uplifted, productive and communicating regularly?
  5. Check progress towards sprint goal
  6. Check burndown -> are we on track? if not, ACTION
  7. Check status of backlog. Do we need refinement?
  8. Is the project budget on track?
  9. Do I need to radiate information to anyone? (project status report, meeting minutes)
  10. Do I need assistance from anyone?
  11. Prepare for Scrum ceremonies
  12. Note any retrospective points
  13. Check in on teams holiday plans

I’ve tried to keep it simple so it doesn’t become a burden but should be enough to cover the ground work. If you have anything else you think should be added, altered or removed I'd love to hear feedback from your experience.

Consultancy Scrum is very different from Traditional Scrum

Having come from a traditional Scrum background and moving into consultancy Scrum, I'd quickly noticed that although the problem it’s trying to solve is the same, the approach is vastly different and more complicated than the former.

Almost all of the articles and books out there are focused on traditional Scrum so it’s not as simple as reading a book and being able to make a start tomorrow. In this blog post I'd like to write about the most common differences that I've come across so far.

Traditionally companies use Scrum to manage and develop their own products using their own resources - they’re facing in-wards. Stakeholders, Product Owner, Scrum Master and the Scrum Team are all part of a single company. Sprints are unlimited, budgets and resources managed by a single entity and the teams never changed.

Using Scrum in a consultancy to deliver a project rather than a product means there are a few key differences in the way we approach the framework but these subtle huge differences can be the making or breaking of a project. We need the process to work, and work well every time, for both the client and vendor.

agileIt needs to have supermaneuverability - ‘the ability of aircraft to maintain pilot control and perform maneuvers in situations and ways exceeding those that are possible using purely aerodynamic mechanisms,’ where the purely aerodynamic mechanisms are those of traditional Scrum.

Non-the less, the goal of Scrum doesn’t change: to get the most important stuff done first with more frequent, demonstrable, releasable software.

Below is a summary of the key differences and challenges there are with consultancy Scrum vs traditional Scrum

Traditional ScrumConsultancy Scrum
Inward facing (single company and product) Outward facing (external project and client)
Product based Project based
Product Owner experienced and knowledgeable about Scrum and the product Product Owner often needs to be identified and requires training about Scrum
Internal Product Owner External Product Owner
Developers are on a single team Developers often on multiple projects
Budget internally managed and fixed Billed on time. Time = money
Organisation has adopted agile Client often not interested in methods used to manage the project
Unlimited number of sprints Time/budget restraints
Constant velocity that’s easily calculated Velocity more difficult to gauge due to shorter projects
Team members are always the same Teams can be as agile as Scrum itself
Aligned on estimates Estimates often require re-calibrating

Consultancy Scrum is a bigger challenge than traditional Scrum because it’s more fluid, reliant on external input and every project has different dynamics. But that forces the teams to become more efficient and streamlined – and fast.

They can’t spend time in meetings about meetings or have retrospectives that last half a day. Every sprint planning, stand-up and retrospective has a direct impact on if the project is successful.

So where’s the best place to start with applying Scrum to a project? That’s a tough one and to be honest, all aspects of Scrum need care and attention. I know that putting the effort in at the beginning;  identifying and training the Product Owner, having clear project goals across everyone involved, a well groomed and beautiful backlog and as always – identifying those risks and dependencies with a plan to mitigate as early as possible is the best place to start (not forgetting having a great team to work with!)

Different teams and companies will have different approaches, it’s up to the team and Scrum Master to find what works for them.

If anyone knows of any other differences, has any advice or horror stories, it would be great to hear from you!