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:

PBI cycle EN

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:

I am the Product Owner of enterprise software.  We believe that our users are disconnecting from our platform because we do not have communication features. To convey that in my Product Backlog, I write a Feature PBI that titled “Email” with the following value statement:  “We want our users to communicate more through the platform in order to stop them from leaving.”

After a few months, when the feature enters the short / medium term, we refine it. In this scenario, “we” is me, the Development Team as well as a few users.

We initially brainstormed on the possible actions a user can do with an email.

Write, Edit, Delete, Read, Send to a single person, Send to multiple, CC, BCC, Archive, Filter, Save as Draft, …

We first started to consider requiring just the Write, Send and Read to start delivering value, when a developer suggested that it would be very easy just to integrate a chat platform, which is basically “write, send and read.” At which point a decision could be made:

  1. We keep the Feature in the Backlog and document the user actions as Acceptance Criteria of that Feature. We then write a PBI to implement a Chat functionality.
  2. We ignored the Chat suggestion based on the users’ feedback and write new PBIs for the User Actions, with the Write, Send, Read PBIs on the top. Some or all the secondary ideas may be removed as we learn from the market.
  3. We keep the Chat suggestion by writing a PBI for it and we still create and order the Email PBIs.

In this scenario, if we split the “Email” PBI, it will be replaced in the Product Backlog by PBIs representing the user’s actions. There is no need to track its implementation as we are tracking the release and/or the impact on metrics.

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.

Luc St-Laurent

Luc is a certified Scrum professional (CSP) and an Agile coach. He began his journey in information technology more than 20 years ago, well before adopting the Agile values (2007). He is dedicated to helping teams and managers to better collaborate and deliver to the user a product of higher quality.
Luc believes in personal development within the team and development of the team within the organization. He longs to believe in the development of the organization within our society.

Previous post

C’est extra! (It's Great!)

Next post

Finding peace (AGAIN) in the heart of the storm

No Comment

Leave a reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.