Recently, someone asked our community what the life cycle of a user story is and how it differs from that of Epics, Features and Themes. I want to share my reflection on the subject.
The first question that popped in my mind was: “Are Product Backlog Items (PBIs) created equal?”
PBIs represent work to be done on a product and document the value of that work. Although the way work is described may change, they all follow the same cycle:
The “how” of each of these steps is defined by each team and will most likely differ based on the type of product backlog item. Epics, Features and Themes are all potential PBIs following the same steps.
Capture
This step is where ideas are generated and documented. They can come from a variety of sources including ideation workshops, direct customer feedback, support, stakeholders, competitors, etc.
A large portion of captured ideas never make it to the Refinement step. They are usually evaluated negatively against expected outcomes and are simply removed. Ideas that are kept are turned into PBIs.
My first Product Backlog contained 2,000 PBIs. I could not cope with the idea of removing any ideas. I thought the Product Backlog was the place to document all ideas. Needless to say that keeping such a Product Backlog ordered and highly visible was an impossible task.
If it’s older than six months, reconsider its place. If it is important, it will come back.
Regrouping PBIs in Themes, Epics, or Features is a great idea to keep your backlog tidy and understandable. Like any other PBI, the value of doing the work is documented. The trick is that sometimes all PBIs linked to such a group are junked (yep, junked!) The reason is simple: by the time you start refining a Theme / Epic / Feature, many things may have changed and you may have learned more on the subject. When time comes, you will refine it and generate more relevant ideas.
Refinement
The objective of refinement is to better understand work coming up and to ensure that each item is as small as possible. The benefits of having small items include a faster learning cycle, easier to estimate work effort and faster value delivery.
Refinement activities include breaking down big items, detailing the small ones and often include evaluating work effort involved. The part that interests us here is “breaking down big items”.
During the refinement activities, the product development team, often aided by stakeholders, work to split big items and explore Epics, Themes and Features. The result of the activity should be a new set of PBIs that we think are needed to achieve the value of the big PBI. Then we discard the big item. The reason is simple: if we don’t remove them, we will end up with dependencies and duplicates inside the Product Backlog, thus creating confusion.
As a Product Owner, I used to keep my Epics and Features in order to track work progress. After a few months, I ended up with six in-progress Epics and I had to track dependencies for each of them. It simply added more work and it told me I was pretty bad at splitting work.
That is when I started to focus on the impact I wanted to generate and finding relevant metrics. I will illustrate this point through a scenario:
|
Development & Delivery
I have seen many teams that stop tracking their PBIs once the item is set to “Done”, i.e. “Released” or “Ready to be released.” Personally, I like to keep them around until the Validation step as a reminder of our Value assumptions.
Validation
I have seen people working tirelessly on products, night and day, never validating their work, never releasing until they thought it was finished. I have seen the death of small businesses and the burning of millions in investment, simply because they feared to fail by showing something too soon.
At this point, each team will find their best way to validate their assumptions. Some teams make Validation a part of their Development & Delivery process. These teams are doing or are on the verge of making continuous delivery. PBIs are then junked once validated.
Other teams either keep their PBIs as hypotheses to validate or aggregate them in larger elements of value. This works well as long as we do not only follow the business impact of the delivery. Most importantly, we need to validate the Value to our users.
In my Email scenario above, it could be tempting to validate “Are our users staying in the platform after the release of the Email feature?” That’s assuming that we know ahead of time what the feature will do and look like… which is arguably never the case. We need to validate that we deliver value to our assumed user for each Write, Send and Read PBIs.
With that in mind, let’s conclude that keeping PBIs until they are validated could be a nice way to complete their life cycle.
No Comment