Product Backlog Workflow

The emergence of the Kanban Guide for Scrum teams has given new metrics and practices to growth groups on how they’ll increase their dash backlog to handle their work. As these advantages are increasingly built-in inside growth groups, there’s one other backlog within the Scrum Guide which may profit from the identical metrics and practices. And that’s the product backlog.

Based on the Scrum Information, the product backlog is “an ordered record of every thing that’s recognized to be wanted within the product”. This can be a nice place to begin for the enterprise to record what is required within the product. I additionally discover it has disadvantages because the lifetime of the product goes from a few weeks to a few years. As time goes by, PBIs begin piling up within the product backlog. Extra stuff is available in than truly comes out. Different individuals create PBIs within the product backlog. The product proprietor lacks the time to correctly evaluation them. It could actually then develop into a multitude whereas the product is having success available on the market. On this article, I clarify how Kanban metrics and practices can leverage the best way PBIs stream via the product backlog.

Kanban metrics for the product backlog

The Kanban Information for Scrum groups identifies Work Merchandise Age as being “the amount of time between when a work item started and the current time”. Whereas it is a useful metric throughout the dash backlog, let’s see how we are able to apply it to the product backlog.

Earlier than a PBI spends time within the dash backlog, it’ll usually spend time within the product backlog as nicely. Examples of actions on PBI whereas within the product backlog are: refinement of the PBI, sharing its information with the event workforce and making ready the PBI for growth. After an period of time spent within the product backlog, it results in a dash.

Within the following picture, we take a look at the product backlog from an getting old perspective, that means for a way lengthy (or previous) every PBI has been within the product backlog. The Y-axis reveals the variety of days the PBIs have been there. On the prime of the picture, the place it says WIP: 119, it means the product backlog has 119 PBIs.

The age of PBIs in the product backlog

Through the use of the PBI age, it offers the Product Proprietor extra readability on the time spent by every PBI in his product backlog. Whereas it may make sense for the Product Proprietor to have a number of concepts in flight, I consider it’s affordable to ask the Product Proprietor how lengthy the concept ought to truly be in flight. Wanting on the picture above, a Product Proprietor may begin by reviewing the oldest PBIs (those on the prime) to see if they’re nonetheless related. After greater than 400 days (that’s greater than a yr) spent within the product backlog, is the PBI nonetheless significant?

Our second Kanban metric, the Work In Progress, reveals the product backlog holds 119 PBIs. This could possibly be seen as an affordable quantity of labor. However, I’ve seen product backlogs with greater than 500 PBIs in them. One can ask the query when there are sufficient PBIs within the product backlog. As we educate growth groups to restrict their work in progress to decrease their cycle time inside their dash, we may do the identical with the product backlog. By limiting the work in progress throughout the product backlog, PBIs will spend much less time within the product backlog.

Our third Kanban metric, cycle time, and it’s distant cousin, the Service Degree Expectation (SLE), will also be of use within the product backlog. When capturing the SLE of the dash backlog workflow from my present growth groups, I usually get values between just a few days all the best way as much as being near the period of the dash.

Now what can be the specified SLE for a PBI within the product backlog workflow? I don’t assume there’s a particular reply. On the similar time, I consider it needs to be recognized and mentioned to see if that SLE is sensible to the Scrum workforce. Within the following picture, you possibly can see the cycle time scatter plot for the product backlog workflow of a Scrum workforce. Sure, that is actual knowledge taken from a product backlog for a full yr with 728 accomplished gadgets.

Product_Backlog_SLE

On the prime proper, the Abstract Statistics field states that:

  • 50 % of the PBIs take 4 days or much less to undergo the product backlog workflow
  • 70 % of the PBIs take 20 days or much less to undergo the product backlog workflow
  • 85 % of the PBIs take 267 days or much less to undergo the product backlog workflow

As I used to be saying above, I don’t assume there’s a particular reply on what is an efficient SLE for the product backlog. However, I discover it helpful to have the dialog with the Product Proprietor to see if it is sensible to have such a niche between 70 % and 85 %.

Primarily based on my expertise with Kanban metrics in Scrum groups, I’ve witnessed product backlog SLE of 89 days or much less, 85 % of the time and in one other Scrum workforce, it had a SLE of 59 days or much less, 85 % of the time. In each instances, the variety of PBIs within the product backlog was over 150 gadgets.

Because the Product Proprietor is utilizing Kanban metrics on his product backlog, it additionally opens the door to new insurance policies for the product backlog workflow. What’s the most age a PBI will be within the product backlog? Does it make sense to have greater than 100 PBIs in there? Is it getting tough to flick thru the product backlog with so many gadgets? Is the present SLE acceptable and if not, what can we do to decrease it? A retrospective could possibly be alternative to work along with your Scrum workforce at answering these questions, main them to new visualization, workforce and pull insurance policies across the product backlog.

Recommended For You Webcast, March 11th: How to Boost Retention and Monetization with Customer Engagement
Register Now

From record to workflow

Even with the Kanban metrics perspective, our product backlog remains to be an ordered record as we’ve seen within the first picture of this text. Let’s use the primary Kanban apply, Visualization of the Workflow, to realize extra transparency on this ordered record.

When utilizing Kanban with Scrum, I discover our intuition is to naturally visualize the dash backlog workflow. We add new columns. We set WIP limits. We outline pull insurance policies. We actively handle PBIs in progress. Nothing prevents us from doing the identical with the product backlog.

To get us began at reworking our record right into a workflow, I’ve discovered the Definition of Prepared between our Product Proprietor and his growth workforce place to begin. One other place to seek out inspiration is at refinement conferences. By listening to conversations at that assembly, you possibly can uncover implicit columns the place PBIs are within the product backlog.

Let’s take a quite simple Definition of Prepared with the next gadgets to clarify what I imply:

  • Acceptance standards are written and understood
  • Scrum workforce accepts person expertise artifact
  • All technical dependencies have been resolved
  • Exterior dependencies are recognized

The third merchandise on this record signifies there’s some technical work to be performed. Perhaps a developer has to evaluation the affect on the code of the PBI at present within the product backlog. Perhaps a fast experiment with one other workforce’s API must be prototyped. All of this in all probability means a column named “Technical” within the product backlog will emerge.

The second merchandise within the record above, Scrum workforce accepts person expertise artifact, appears to point there’s some kind of UX being concerned. This might underline a UX column within the product backlog.

From my expertise, I’ve seen the next columns emerge in a product backlog workflow:

  • To evaluation: An entry level column the place the PO checks if she accepts the brand new PBI in her product backlog. Examples of labor on this column are checking if the brand new PBI is a reproduction of an present one or asking a developer to research if the PBI is technically potential. By placing this column because the entry level, it invitations due diligence on the PO to evaluation new PBIs.
  • To do: From what I’ve witnessed, that is the column of the product backlog with probably the most PBIs in it. It incorporates previous bugs, want lists, requests saved alive to reassure a stakeholder and PBIs that might be coded (at some point) to call just a few.
  • Technical: Something that wants some technical consideration (Ex: technical evaluation of a proposed answer, proof of idea lower than just a few hours, high-level technical answer to get settlement).
  • Useful: Something associated to UX (Ex: screens, logos, wording)
  • To Refine: PBIs which might be reviewed throughout a refinement session
  • Refined: PBIs who have been refined and are prepared to enter the dash backlog
  • Candidate: A holding column for PBIs which might be prepared for the following dash

Please observe that not all these columns seem within the product backlog workflow nor are they on this particular order. They’re a compilation of what I’ve seen up till now. In the event you’ve labored with extra columns in your product backlog workflow, be at liberty to record them by writing a remark on the finish of this text.

Our second Kanban apply, Limiting Work In Progress (WIP), will be of worth for particular columns of the product backlog. Let’s take for instance the Candidate column. Within the following picture, it’s the final column of the product backlog. We present the interconnection between the product backlog and dash backlog workflow via the Candidate and Prepared columns.

Product_Backlog_Interconnection

The Candidate column holds PBIs that are prepared for growth. They’re held there till the event workforce requests extra work, whether or not initially of the dash or when the event workforce requires extra work.

We are able to set a WIP Restrict on the Candidate column of about the identical dimension because the Prepared column of the dash backlog. As it’s the column for pending PBIs prepared for the following dash, we wish to restrict the variety of gadgets on this column. If the event workforce has a WIP restrict of 10 PBIs per dash, my proposition is the Candidate column has round 10 PBIs.

Product_backlog_interconnection_WIP_limits

The Technical and Useful columns may also have a WIP restrict. In a single Scrum workforce, we overloaded the event workforce by placing too many PBIs within the Technical column. Builders paid extra consideration to the work on this column and forgot to concentrate on their work within the dash backlog. By placing a WIP restrict of 4 on the Technical column, it restricted their time spent on these PBIs in the course of the dash.

On events the place I’ve helped develop the product backlog right into a workflow, I’ve additionally been witness to extra engagement from the event workforce. As extra transparency is gained within the product backlog workflow via columns and insurance policies, a few of them would require a contribution from builders. I’ve discovered this to open up the dialog on the extent of engagement requested by the event workforce on upcoming necessities. This new degree of transparency offers builders visibility on what’s developing and what they need to do to organize the PBIs earlier than they’re coded. Of their pursuit in the direction of self-organisation, it reveals them the work to perform.

Prodcut_backlog_unkown

Nevertheless, I’ve had builders react negatively to this new degree of transparency. Some arguments I’ve heard have been how their time is solely devoted to the dash backlog and the product backlog is the realm of the Product Proprietor. On one other event, builders initially didn’t know methods to manage their time between PBIs within the dash and product backlog workflow. On this final scenario, having a refinement assembly in the course of the dash would assist builders concentrate on PBIs within the product backlog in the course of the dash.

In conclusion

I consider a product backlog workflow is a serious enchancment on the preliminary record talked about within the Scrum Information. Kanban practices and metrics provide extra visibility to the Product Proprietor on what resides within the product backlog. It offers her an extra toolset on methods to handle her product backlog.

Whereas the time period DevOps continues to tighten the hole between builders and operations, the BizDevOps pattern, the place the hole between enterprise and software program growth additionally tighten, could possibly be initiated with a extra visible and restricted WIP product backlog workflow. Solely the long run will inform us.


About the Author

Leave a Reply

Your email address will not be published. Required fields are marked *