I love my work. Implementing Scrum is fantastic. Every company I work with has different processes and cultures. Coaching teams in this drastic new approach we call Scrum is always fun (afterwards). Working with people, breaking traditional patterns in common sense, creating a physical/visible presence, and fostering honest communication is a roller-coaster experience. Every team is unique, every time surprising me with interesting reactions and sometimes unexpected results.
In the past, some of these unexpected results have sprung from my attempts to explain the concept of a product backlog item (PBI). For teams raised in traditional development, the ins and outs of product backlog items can be difficult to grasp. When I talked with these teams about PBIs, I made the mistake of going into too much detail too early. I would start with the definition, explaining that a PBI is "up to half of an A4 page describing a requested feature from a market point of view." This, while a correct description, opened the floodgates for the skeptics and perfectionists within the team, who asserted that there was no way they could write a complete product backlog item in that amount of space. We would get off track, and it would take me some time before I could refocus the team.
I have since determined that providing a detailed definition of a PBI is not a good idea for new teams. New Scrum teams are floating; they'll hang-on and stick to anything they can comprehend. The team is not yet used to working on a global idea, enriching it with their impressive but unexploited domain expertise, and then clarifying it by means of interaction. I now have a different approach. When first explaining product backlog items to teams I start at a higher level. I avoid delving into details about the PBI itself and instead focus on the workflow of a PBI and the interaction with the Scrum framework.
Since I started focusing these initial discussions on workflow, I've seen much better results. The starting definitions and work flows that I share below help me and my company train teams on how to implement the often complex problem of backlog management. We share the concept with you in case it helps your team in its struggles to implement Scrum well. Remember that this is just a best practice, a generic approach. Teams using this concept should adapt it to their personal taste (as may be expected from a good Scrum team).
Product Backlog Item Lifecycle
So, what is a product backlog item? Nowadays the answer is not that explicit. Our answer:
"It can be anything, a written request for something in the interest of the product. That something may be technical or non-technical, may be described on high level only or go into detailed depth. It depends..."
At a certain point, a PBI must contain sufficient detail so that the development team is able to realise the request described in the PBI and the product owner is able to prioritise the PBI. It is therefore important that the Scrum team understands how to deal with PBIs. Where in the process does the Scrum Team have influence? Because a picture says more a thousand words I have summarized a basic PBI lifecycle in a simplified state transition diagram:
A PBI Being born:
- A creator (C) adds a PBI. A creator can be anyone (Scrum team or stakeholder). The creator is responsible for transitioning the PBI to Waiting for Inventorisation.
Maturing of a PBI:
- A development team member with the architect, an optional, rotating role (A), frequently check the PBIs that are Waiting for Inventorisation and make a rough impact analysis in preparation for the size estimation by the development team. This may require interaction with the creator. When the impact in relation with current design is understood, the architect transitions the PBI to Waiting for Team Estimation.
- Team estimation should take place regularly. As an example, one team I know of has a default reservation for a room, twice a week, specifically for product backlog development team estimating. If five or more PBIs are available on the evening before the meeting, the meeting will take place. If there are fewer then five PBIs and the meeting is not the last in the sprint, the meeting is cancelled. During the meeting the architect briefly explains the PBI and the development team asks questions. If the questions can be answered and the development team understands the global idea, planning poker is used to indicate the size (based on three reference stories). Once estimated by the development team (T), the PBI is set to Waiting for Prioritisation.
- A regularly planned meeting, at least one per sprint, should be reserved for prioritisation. The Scrum Master supports the Product Owner (P) with prioritisation. How prioritisation is done is outside scope of this article, but in the end the PBI is assigned a priority value. The Product Owner assigns the value and the PBI goes to Prioritised.
A PBI is part of the prioritised product backlog and waiting for realisation:
- With the priority-value-sorted Product Backlog in place, the Scrum team can do the work of sprint planning. Starting with the highest-valued PBI, the team identifies the tasks that need to be performed in order to realise the PBI and estimates each task in ideal hours. They continue to do this for as long as PBIs fit into the sprint budget. Every PBI that is assigned to the active sprint is set to Sprinting.
Planned in a sprint, Scrum in progress:
- When a PBI in the active sprint is finished and quality checks are performed, the owner (O) of the PBI, transitions the PBI to Sprinting Done. In my development teams, every PBI has an owner. Especially when working with multiple team members on different tasks for a single PBI, it is always good that one has the general overview.
- During the demo, all Sprinting Done PBIs are presented to the product owner. When the Product Owner has announced a verdict (positive or negative), the PBI is Closed. In case of a negative verdict, new stories or bug reports might be issued. The sprint is failed but the PBI is Closed.
End of life
- A PBI may never be deleted. The end of life of a PBI is always traceable to Closed or Obsolete.
After this basic PBI state transition diagram is used as a stepping stone, it is my experience that the new Scrum team feels on solid ground. The precise meaning of the content of a PBI is not under discussion anymore because there are enough safeguards built-in before actual realisation starts. The PBI state transition diagram is the fundamental basis for the entire PBI handling process. The process needs to be extended with actions, ownerships and responsibilities but start simple. If required, the retrospectives will tune the process and make it suited for your Scrum team.
The initial elaboration of the PBI state transition diagram is a Scrum team effort. It increases commitment considerably if you let the Scrum team discover their process definitions. The discovered basic process will look much like above scheme, but might use different terms or the same terms in slightly different ways.
To facilitate this elaboration, draw a rectangle in the center of a whiteboard. Label it Waiting for Prioritisation. Discuss what input is needed from the development team to support the product owner in deciding on priority. Elaborate your way up and position the Born and Maturing phases. If the upper part is in place, work your way down. Position the PBI in the Scrum framework. Having the Scrum team discover this process through elaboration is essential: It allows the team to own the process and keeps anyone from having to behave like a referee, continuously hammering and explaining a process that the Scrum team might not understand or is reluctant to follow.
One important aspect that is not part of the basic PBI state transition diagram should be considered: small and big PBIs. Small PBIs can be accepted as-is or be combined by creating a new PBI and making the originals obsolete. Big PBIs (sometimes called epics or umbrella PBIs) require serious thinking through. On most of my Scrum teams we allow Umbrella PBIs to exist as long as they have a low priority value. Once these PBIs become a high priority, however, they have to be split into multiple new PBIs. The Umbrella PBI is completely emptied; it only contains references to all derived PBIs. One of the derived PBIs must be the integration testing of all the other derived PBIs. On these Scrum Teams, we added another possible End-of-Life state called Split (in addition to obsolete and closed). Split is the state assigned to all of the emptied Umbrella PBIs.
For those interested: The Umbrella PBI was fully emptied to maintain traceability and continue having a simple process. Setting a PBI to Split keeps the big size estimate in place and avoids changing a PBI description or combining it with an identifier that might have a certain historical association. We did consider using the Umbrella PBI only for the integration task of all derived PBIs but decided this would require additional Split status definitions, thereby increasing the process complexity.
Keep the Product Backlog Alive!
Maturing and prioritising is not a one-session-per-PBI-only experience. Prioritisation is a continuous process. Markets are changing, experiences and competences are increasing. We simply gather more information and knowledge over time. It is strongly advised to have an alignment meeting on prioritised PBIs between Scrum Master, Product Owner (and the optional rotating role Architect) to keep the product backlog prioritisation up to date (plan for this to happen sometime mid-sprint). Make sure that process impact from this alignment meeting is incorporated in your PBI lifecycle.
When the Scrum Team has the PBI state transition diagram elaborated you can choose a supportive product backlog tool. A lot of tools are available. None of these tools is perfect simply because every project is unique by nature. Make sure that the defined processes can be reflected by the chosen tool. I will not sum up the tools we have been using because it is impossible to advise a generic tool. PBI tools can be used standalone or become an integrated part of you configuration management processes. If you are unfamiliar with tools or with the requirements, start using a spreadsheet, gather your requirements and decide with the team if and how you want to incorporate steps in the configuration management process. Google around and use virtual images to play and learn. In the end any tool that matches your requirements will do the trick if used in combination with common sense. Keep evaluating your tools during the succeeding sprints. Do not be afraid to adapt or even change to new tools. Supportive tools increases productivity!
Dealing with product backlog items is one of the major steps in transitioning to Scrum. Grasping / understanding the PBI workflow is, in my opinion, best explained by starting with discussing the PBI lifecycle. The creation of a PBI state transition diagram substantially helps position the PBIs in relation to the Scrum framework. With a procedural safety net in place, defined, and accepted by the Scrum team, the specific details for PBIs are of lesser importance. A defined lifecycle helps the team understand that, before it starts to realise a PBI, that PBI should have been evaluated by everybody on the Scrum team, so that everyone has a chance to clarify the intention of the PBI.
Author's notes: Implementation is carefully avoided in relation with PBI fulfillment. Implementation is too easily associated with coding/making it yourself. Instead I prefer the word realisation, which leaves more room for alternatively achieving a PBI. Also, in this article when I refer to a Scrum team, I mean the whole team (product owner, ScrumMaster, team members). If I want to talk solely about the team members, I refer to the development team.