Establishing the first common product backlog

The past few days at my current coaching assignment have been great. We created a new backlog for all work they need to accomplish in the months ahead. The meetings where we laid the foundation for the future were marked by a high degree of collaboration between the participants and energy. It has been really fun to work with them so far.

The organization previously had several parallel projects run by the business. The different project leads tried to get control over their projects by talking directly to the different developers and getting them to accept their tasks before other work. They did this not only to guarantee a successful result for their own projects but also because there was no structured and defined process to request new functionality from the development team. The prioritization was pushed down to the development team.

One way to mitigate this is to establish a product owner team responsible for delivering the maximal value for the whole organization, shifting the focus from the different projects to the organizations needs instead. So last week we established a product owner team, which includes the technical project managers as well as the business people responsible for the different product areas.

The product backlog

The product owner team started out by creating one common product backlog that is prioritized according to business values. The product owner team is responsible for the backlog from a business perspective and creates minimal features that are valuable and marketable, so called Minimal Marketable Features (MMF). The development team can then analyze these features and break them down into user stories of smaller granularity if necessary. The difference between features and user stories is that the former is something that is valuable and releasable, but the latter is something that is demonstrable but not necessarily releasable in isolation. Features are tools for the business, and user stories are tools for the development team to organize their work during the iterations.

Once the product owners were done creating the product backlog features, we held two meetings, one to prioritize the features and one to estimate the amount of work necessary for each feature.

Prioritizing

After creating the backlog, the product owners prioritized the features, but we could see that some of the “must haves” were prioritized quite far down in the product backlog. They had prioritized according to the business value each feature had, and some of the basic ones did not add so much value, but in reality the product would not be releasable without them.

To mitigate this we did one more prioritization but this time according to the Kano model where the features were categorized according to four categories: basic, key, plus and secondary. The categories are two dimensional; the first dimension indicates if a feature gives the organization or user positive value if it is included in the application, and the second one is if the feature gives the organization or user any dissatisfaction if it is not included. This can be modeled with a tuple (a, b) where the first value is the effect if the feature is included and the second the effect if it is not included.

• Basic (0, -): Features that are needed in order to make the product usable. This is functionality that does not add any value if included but will hurt if it is not present in the product when released.
• Key (+, -): Features that will make the product interesting to use and differentiate the product compared to the competitors. These are the features that will give the organization positive value if they are included but at the same time will hurt the organization if they are not. The product will need most of these features to make the product successful
• Plus (+, 0): Features that will give the organization positive effect if they are included, but it will not hurt it if they are not present. The organization should have as a goal to include some of the features in this category.
• Secondary (0,0): Features that do not affect the organization or user regardless if the features are present or not. The product should not include any of the features listed under this category.

The product owners worked collaboratively at the whiteboard to categorize each feature. It was really fun to see how the participants helped each other work through all features, regardless of which project the features belonged to. They discussed and helped each other to find the correct categorization according to the future needs and goals of the organization and product.

Once the product owners had categorized all the features, they prioritized the all the basic ones. They placed the features collaborative on the table according to its business value and according to when the feature is needed due to upcoming releases. I then asked the product owners to identify all the features in the key category that they felt had to be included in the release, and prioritize them into the backlog on the table as well.

During this meeting we also drew a project timeline with important dates and deliveries. The goal of the timeline is to visualize the releases and also clearly state the business case behind each release. It is important that everybody in the product team as well as everybody else participating in the product development has the same view of future releases and prioritization, and also reasons for the plan ahead. The participants need to know what’s at stake from a business perspective in order to be able to make sound decisions during the development.

We decided to serialize the projects into two month planning cycles. The planning cycle is not a project with one deployment and release at the end of the cycle; it is a platform for collaboration between the product owners that can span several important release dates or milestones. The planning cycles allow us to create release burn downs that will show us where we are regarding our business goals, something that was lacking before.

The timeline was a great help during the prioritization since it made the future milestones and important dates visible for all participants; everybody got a shared understanding of what was important to maximize the business value.

We ended the meeting with a discussion of what needed to be included in the first planning cycle to deliver the desired business value. The product owners agreed to the scope, which after a discussion with the development team will be the target for the first release, and monitored with a release burn down.

Estimating

We followed the prioritization meeting with an estimation exercise where the developers estimated the product backlog. We had around 30 features to estimate, so we needed to find an efficient way to do it fast and energizing at the same time. I decided to use T-shirt estimation together with planning poker.

We divided the group into two sub-groups where each group in parallel estimated one half of the features. The groups sat at the opposite sides of the table in the same room, so they could hear each other and provide input if necessary. A couple of product owners sat with each group so they could describe the intent and meaning of each feature during the estimation.

The goal for the first step of this estimation exercise was to categorize the features into small, medium and large features. This step took around 50 minutes to complete. When all features had been categorized we had a quick validation of what each group had done by letting the groups inspect each other’s estimation. The groups described for each other the reasoning behind some of the categorized features.

Finally we used planning poker on a couple of medium stories to agree to the number of story points to allocate to the medium category. We then assigned half the story points to the small category and three times more to the larger category.

Summary

The team had a couple of really productive days where they established one common, prioritized and estimated, backlog for the cycle that ends at the end of January.

The establishment of the product owner team will help the organization to create a common goal for their work, and to optimize the whole rather than the parts, across the different projects. The product owner team will also create a better interface to the different development teams working on the backlog. It will be easier to establish good collaboration on what they should accomplish now when the product owners have a better way to synchronize with each other.

Finally, the different practices that we used, which I have described in this post, have been great in both creating a valuable outcome, but even more importantly, in helping the team collaborate and communicate productively. It has been really fun to be part of this process!