Maintain One List of Work
Posted by Chris Sterling on 12 Jun 2009 at 06:44 pm | Tagged as: Agile, Architecture, General, Leadership, Product Owner, Scrum, Software Architecture, User Stories, XP
During an interview at the Better Software conference this week, I mentioned that I thought maintaining a single list of work prioritized by the business was important for our industry to improve. The following text is an excerpt, in first draft form, from chapter 2, “Architecture Integrity”, of my upcoming book “Architecture in an Agile Organization” that is relevant to this topic.
In Scrum, the Product Backlog is a list of desired features prioritized by the Product Owner. Prioritization is done by the Product Owner to optimize value of the software delivered to the users. Instead of prioritizing within levels of importance such as high, medium, and low the Product Owner must prioritize in “stack-rank” order. This means that no Product Backlog item has the same priority as another item. This form of prioritization gives clear directions to development teams about what the most important feature is next to work on.
A healthy Product Backlog contains not only new features but also technical requirements to support the next Product Backlog items in priority. The development team is expected to review the Product Backlog frequently to provide cost estimates for Product Backlog items to help the Product Owner prioritize based on both cost and benefit. During the development team’s review they will suggest Product Backlog items that are missing from a technical point of view in the product definition. These technical Product Backlog items will be discussed with the Product Owner so they are able to prioritize them effectively. It is essential that the development team explain why each technical Product Backlog item is important to support other upcoming items. If this is not expressed the Product Owner could be inclined to demote those technical Product Backlog items because the value of them is not understood enough.
When issues are found in the software they usually come in three varieties:
- Enhancement – a suggestion for improving the current state of the software from a user’s point of view
- Defect – a system fault that occurs while using the software
- Fire – a system fault that is inhibiting significant usage scenarios in the software and must be fixed immediately
Enhancements are requests for improvements to the software based on the perspective of the user. These improvements should be prioritized based on their value against all other Product Backlog items. An enhancement and defect issues are hard to distinguish from one another at times but that is fine. Defects are system faults that users are able to workaround but should not be happening from a user experience and/or technical perspective. Since we are able to work around these defects and the development team is able to provide a fix in the next iteration they are placed into the Product Backlog and prioritized against all other Product Backlog items. Fires are defects that cannot be worked around and cause serious problems for users of the software. In healthy software applications, fires should be a rare occurrence. It is important that a fix is implemented right away and may interrupt the work getting done in the current iteration.
Figure: This flow diagram describes how an identified issue is triaged in an iterative and incremental approach such as Scrum. If the issue is an enhancement or defect that can be worked around for now it goes into the Product Backlog and prioritized based on its value. If the issue is a “fire” or defect that cannot be worked around then it must be fixed immediately. The development will put the fire into their current list of work in the Sprint Backlog and figure out how it effects their commitment to deliver on their current iteration.
Defects are captured in bug databases in many organizations. Teams using the Scrum process to manage their software development find themsves in a predicament. Do we continue working from two lists, the Product Backlog of desired features and bug database? Or do we incorporate items from the bug database into the Product Backlog? I suggest all teams should incorporate defects into the Product Backlog. There are multiple reasons to do this:
- Development team does not make priority decisions for the business stakeholders. If the development team decides to work on defects rather than desired features then they are deciding the defects are higher priority than the desired features without including the Product Owner in the decision-making process.
- Minimizes the amount of hidden work done by the development team. By providing visibility into the defects, the development team is being transparent about the state of the software they are working on.
- Provides the Product Owner with an opportunity to prioritize the defect lower. The Product Owner could decide the defect is not important enough to fix at this time.
- Allows development team and Product Owner to design a solution for dealing with defects. From time to time the defect provides insight into a design flaw that the Product Owner would like to improve.
Ultimately, the development is able to maintain alignment with business priorities for the software. Priorities are decided based upon the full reality of the software, new features and defects included.
A single work queue, such as the Product Backlog, provides visibility to the development team about current expectations about upcoming work. The Product Owner should share the Product Backlog with the development team and discuss the direction of the product beyond the next iteration. As the development team gains knowledge about the direction of the product they will be able to provide input into the Product Backlog. This visibility is important so Product Backlog items do not surprise the development team when it is too late to prepare a proper solution.
Very good point.
The transparency and singleness of purpose provided by consolidating to a single prioritized list of what needs to happen next can only help the Product Owner feel in control of how and where their budget is being spent - and I like how you strive to expose the hidden work that developers are often not appreciated for and which frustrates the owner.
Some Product Owners may become frustrated that these additional entries in the backlog clutter the prioritization of features. In this case, perhaps encouraging them to publish a separate roadmap communicating the high-level, strategic directions/features currently being considered (but not committed to) may prove useful - AS LONG AS this is never confused as being the Backlog, the _tactical_ tasklist the owner has signed off on and which the development team is to take marching orders from.
[…] Chris Sterling’s Blog » Maintain One List of Work […]
We often find ourselves in the predicament you describe. Are you using points and velocity? The challenge we have when working from a single work queue is people expect to see points for defects, which always proves to be unreliable and skew the velocity.
Yes, we do. There are a couple of things that are important. If the bug is existing, we might bundle it into a group of bugs and then fix as many as possible within a defined story point budget. Or we could just not give any points which allows your velocity to just be what it is while catching up on fixing defects. In most teams I work with nowadays, with smaller codebases and less technical debt, they do not create any significant bug count at all and so fixing defects just doesn’t happen often enough to get them in the PB. Those are highly experienced Scrum with XP technical practices teams and it has taken time for them to get like this. The idea with maintaining one list of work is to make it difficult so that the threshold of pain is low and people will do something to fix the situation or it causes more pain.