I’m back from Nashville having made it through four days of sun, rain, and country music pretty much no worse for wear (apart from a fouled up sleep pattern that’s slowly getting back to normal).
I got the opportunity to get a behind the scenes view of recorded music when I toured Zac Brown’s Southern Ground recording studio. During the tour, it occurred to me that recording music can be very similar to developing software products. The people who truly have a passion for both pursuits don’t get hung up on process, but use process to help get them to great outcomes, whether that be an artistically pure recording or a product that solves customer’s problems.
Now that I’m back, I wanted to share how the team I’m working with right now performs backlog refinement. This is still very much a work in progress, which I think is perhaps one of the more important points.
That means the approach we use for backlog refinement a few months from now will probably be different than what we’re doing right now. And that’s a good thing.
Definition of ready
As we started diving into delivery work, I pulled the team together to craft a definition of ready – our agreement of what information we needed to know about a product backlog item in order to consider it in a sprint.
To generate the definition of ready, we gathered around a whiteboard, and I asked everyone on the team to write down – one idea per sticky, as many stickies as they wanted – what information they expected to know about a story before including it in a sprint.
Everybody put their notes up on the whiteboard reading each note off as they put them on the board. We then reorganized the notes, getting rid of duplicates and asking for clarification on any items that weren’t clear.
Once we had the notes in groups I asked the team to dot vote in order to indicate their preferences about things that should be included in our definition of ready.
We then discussed each item starting with the highest vote-getters and working our way down. The discussion we had about these items was helpful to get clarification on what people mean when they talk about certain things and helped everyone to get a better idea of what type of information people look for when they pick up a product backlog item to work on.
I’ve listed the items we ended up within our definition of ready below. This is pulled almost verbatim from our team wiki (we’re using Microsoft Teams) that I wrote up after we settled on our definition of ready. Also included is a short description of what we mean by each term, and where we’re recording it on our backlog management tool (we’re using Azure DevOps).
A short phrase that conveys the “general gist” of the story.
Where Stored: Work Item Title
A longer explanation of the product backlog item that includes:
- why the product backlog item is needed,
- who the product backlog item impacts, and
- what problem we’re trying to solve.
- As A <Who> I Want <what> So That <Need> or
- In order to <Why> As a <who> I want <what>
Where Stored: Description
Relevant information about the data related to the product backlog item. May include:
- data elements
- API data structure
Where Stored: Description (under Data header). May be links to data dictionary or other resources.
Conditions that the product backlog item must satisfy to be accepted. Consists of a set of statements, each with a clear pass/fail result, that may specify both functional and nonfunctional requirements.
Where Stored: Acceptance Criteria
Relative size of the product backlog item as determined by the team. Represented as a number in the Fibonacci sequence (1,2,3,5,8,13,21…)
Where Stored: Effort
Models (Where appropriate)
One or more models that provide further insight into the product backlog item. May include wire frame, report mockup, spreadsheet showing data calculations, state chart or process flow.
Where Stored: Attachment (if related only to specific product backlog item) or as a link in Description (under Models header)
Concrete descriptions of the expected behavior of the product as a result of the product backlog item using real-life data. Examples are useful for describing a solution and providing guidance on ways to validate it.
Where Stored: Acceptance Criteria (under Examples header) links to examples in outside documents/tools
We’ve discussed product backlog item with product owner and they’ve provided feedback.
Where Stored: Our product owner moves the Product Backlog Item into the Ready for Sprint Planning column on our board (see below)
Other product backlog items that need to be completed prior to start work.
Where Stored: Related Work show links to other product backlog items.Use Predecessor Like type if product backlog item your linking to needs to happen before the product backlog item you’re working with.
Getting backlog items to ready
We established the definition of ready first, because I view that as a great way to influence our backlog refinement process.
Once we established our definition of ready, I sketched out what I thought our backlog refinement process should look like and mocked up our teams discovery board.
The columns on the discovery board reflect the main activities of our refinement process. I’ve listed the columns on the board and the entry criteria for each one below:
Entry Criteria: Title
Ready to Size
Entry Criteria: Title, Description, Data, Acceptance Criteria
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size, Needs Wireframe
Ready for 3 Amigos
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size, Wireframe
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size, Wireframe, Examples
Ready for PO OK
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size, Wireframe, Examples
Ready for Sprint Planning
Entry Criteria: Title, Description, Data, Acceptance Criteria, Size, Wireframe, Examples, PO Ok, Dependencies
Due to the way that Azure DevOps is setup we weren’t able to have a separate discovery board and delivery board. Instead, we have one board that shows the status of a Product Backlog Item from originally being created to getting all the way to done.
We’re a little restricted in our board setup based on organizational standards, so multiple columns are mapped to a specific work item state. The defined states are used organization-wide for tracking purposes.
We’ve incorporated that constraint into our work process by having our product owner explicitly move product backlog items from Ready for PO Ok to Ready for Sprint Planning to provide a tracking mechanism that he “approved” considering that product backlog item for delivery.
Having product backlog items organized into specific columns helps me and the designer (the primary people engaged in getting stories ready) to know what we need to work on next. The columns also help the rest of the team know what product backlog items we need to store, and what items we want to discuss further prior to sprint planning.
Adjusting our backlog refinement approach
When we set the definition of ready and our discovery board, we agreed as a team that both the definition of ready and backlog refinement process were not set in stone and could change based on experience and things we learned along the way.
We’re in the midst of our third sprint and we’ve already made some tweaks, rarely waiting for a retrospective to make those changes. Here are two changes that come to mind (I suspect there are probably others).
Adding the Ready for PO OK column
We initially did not have the Ready for PO OK column on our discovery board, but then we found out that we needed a way to explicitly show that the product owner had approved considering a product backlog item for consideration in sprint planning.
We decided to have the product owner explicitly move items into the Ready for Sprint Planning column because Azure DevOps recorded who moved the product backlog item. This ensures that the product owner considers the stories and also records that he approved it.
We use the Ready for PO OK column to identify the product backlog items that the product owner needs to look at. This is consistent with how we use other columns as a way to create queues for things such as sizing and to identify items that need more discussion.
When we added this process step, we also decided to classify product backlog items as Business or Architectural (using the Value Area field on the Product Backlog Item). We only ask the product owner to move the product backlog items identified as Business. He does not have to move Architectural product backlog items.
Data dictionary in source control
I created a data dictionary in excel to use a consistent means to communicate data information for product backlog items. We decided as a team that we want the data dictionary to closely match what was actually implemented, including things such as specific data types and lengths.
This is helpful from the perspective of keeping long living artifacts up to date, but we started running into a challenge where it was becoming difficult for the team to know when the data dictionary changed in a way that impacted them.
We decided that a good way to address this issue was to include the data dictionary in source control. One benefit of doing that is that everyone on the team can tell which version of the data dictionary is most current. The other benefit is a little more personal, and that it’s I get the chance to learn about git and source control. I’m finding that is definitely good knowledge for a product manager to have.
We also have a few spreadsheets that we’re using for master data – configuration data that does not change frequently, but it is necessary for the transaction processing we need to do. In order to make sure we’re using the most up to date version of that data, we’ve also placed those files under source control.
I suspect as we create more artifacts for other long term system documentation, we’ll put those under source control as well.
It’s all about communication
I shared my experiences here not for the purpose of saying that this is what your definition of ready and discovery board should look like (although feel free to use them if they make sense for you).
I shared them to provide an example of how you can work with your team to craft approaches that best fit how your team prefers to work.
Common practices are good to use as a starting point, but you should always talk about why those common practices are helpful and which ones make sense for your team.
If you have other experiences with backlog refinement, please share them.
Kent J. McDonald
Founder | KBP.Media