How to do your team’s first Backlog Refinement
What to do when starting a Scrum Project
Just like there is more than one way to skin a cat, there is more than one way to start a Scrum-based project. One way we like is to start with a hybrid backlog refinement that kicks off the project and the first sprint all at once. In this article, HammaJack co-founder, Jacob Moran, outlines some of the things he likes to cover.
What you need to cover in your first Backlog Refinement
There’s a lot to cover when you do your first backlog refinement. Below is a list of things to consider, and some tips we’ve picked up along the way.
Board & Workflow
More estimation (if required)
It’s important that you cover the basics, but also get people onboard and excited before you start. That’s why it’s important to talk, at a high-level, and inspire the troops before you get started.
In the project kickoff make sure you cover off;
The Project Goal
Get the Product Owner (or a senior manager) to give their best O’ Captain, my Captain speech on why you’re all here - they’ll love it and if it helps empower just one person it’s a worthwhile exercise. The trick here is to keep it to 500 words or less.
Talk through, how you’re going to structure the project. Please note this is not a time to talk about deliverables. Things that should be covered include;
Framework (e.g. Scrumban)
Estimation (e.g. Fibonacci)
Cycle (e.g. 2-week sprints - Thursday to Wednesday)
Reporting & Documentation (e.g. Jira and Confluence)
Informal Communication (e.g. Slack)
Official Communication (e.g. Intranet)
Go through the ceremonies (Backlog Refinement, Review, Retro & Planning), what they are and why they are important. The team, especially if they are new to Scrum, won’t completely understand the differences but as long as they know the ceremonies exist then you’re heading in the right direction.
This is possibly the most important part of the process. In this part, you need to go through the definition of ready and the definition of done. The trick here is that it is a team-led exercise and not a management-led exercise.
Furthermore, avoid boilerplate definitions. You should do this for two reasons;
This is a learning and bonding exercise and using a boilerplate takes away from that.
Each project is different and has different people/needs, therefore, this will affect these definitions.
Finally, these definitions can, and should, change over time - make them working documents.
Board & Workflow
Go through the board(s) you plan to work from and the workflow you are going to start with. Yes, these will change, but expecting the team to pick up a workflow without an introduction isn’t going to work.
Teams are filled with different personalities. If these teams are new to each other there are going to be growing pains. These pains are unavoidable, however, a social contract can alleviate some of these issues. The easiest way to get a social contract is to run a brainstorming session with the team for no more than 10 rules and then get these rules up onto a wall.
The Actual Backlog Refinement
Once you’ve gone through the project kickoff part, it’s time to get into the actual backlog refinement. In this first backlog refinement make sure you cover;
Introduction to Estimation
Not everyone on the project will be familiar with your estimation technique (if you have one at all). Take the time to talk through the estimation technique, if artifacts are needed (like story point cards), give them out.
Now the team knows how to estimate, you need to calibrate them to each other. To do this you can use a benchmark story. A benchmark story is a story in your backlog, preferably up the top, that you’ll use as your baseline. Some tips for your benchmark story;
Make it small, but not too small
Make it easy to understand for everyone
Make it include aspects from all of the team’s skill set
Once you’ve got your story, refine it and then get the team (yes even the designer/BA who has “no idea” how much work it will be) to estimate the story. This first estimation will be a calibration. Get the team to talk about why they gave an estimation and then estimate again until you have a consensus.
The actual estimation itself doesn’t overly matter, as all you are doing is setting a benchmark.
Next, because you just want to get started, you should do sprint planning. The trick here is to make sure that the team understands that the refinement and planning should happen separately in Scrum. This isn’t true if you are running a Just-in-Time methodology like Kanban, but more on that later.
In sprint planning make sure you cover;
Get the Product Owner to outline in a sentence what they want to achieve in this sprint. The trick here is to not let it dictate what stories they want the team commit to, more the general focus of what we are trying to achieve. Again, if they do this in an O Captain, my Captain style then you are on the right track.
Now the team has to pull in work to the sprint. The key word here is ‘pull’. Scrum is a pull methodology, not a push methodology. The trick here is to only let the people who will be doing the work commit to doing the work. Sounds simple? It rarely is.
More estimation (if required)
If the team feels they can get more done than they’ve committed to (usually not true in the first sprint) then you can repeat the estimation and commitment steps as necessary. But remember, you can always pull more into the sprint.
Now that the team has made the commitment they need to break down how they are going to achieve the stories. This is best done with post-its and different members of the team writing down the tasks. In the early stages, it can help to have a senior member of the team “run-through” the story.
There’s no real trick to sub-task breakdown, just do it in whatever way feels right, but it’s better to over-breakdown than under-breakdown. This won’t be perfect to start with, but the team will soon find their rhythm.
Once you’ve got all the sub-tasks, remember to order them.
Please note, that the beauty of doing it on post-its is that you can always make more/changes/delete where needed.
Most Important Point
If you only remember one thing from this article, make it this;
Your first backlog refinement is going to be long, and it’s going to be painful at times but it’s better to have it done than to try and plan the pain away (because you can’t). Just get started, involve the whole team, be forgiving, be inclusive and start working through your backlog.