Agile Product Backlog Refinement (Grooming)

Feature image by Photo by Crystalline Radical.

 

In my last post, Agile Product Backlog Grooming Reduces Risk, I talked about using Product Backlog Grooming sessions as a project risk mitigation tool. In this post, we’ll further explore the details of backlog grooming with some tips to increase the value of grooming. These tips are for the Product Manager, Product Owner, and Development team to help make the grooming experience valuable and easy.

Development and Product teams begin the process of collaboration before the Product Manager has pitched the new/modified product idea to the business or before anything is actually in the product backlog. At this stage, most if not all information is based on previous experiences and assumptions. However, depending on your business structure, the Product Manager will probably validate most Problem & Solution assumptions prior to presenting the project to the business. The Development person here is the product architect or designated representative of the team(s) familiar with the product.

  1. Product Manager gets an idea (from any source) on how to achieve business goals with his or her product
  2. Product Owner and Development discuss feasibility of the idea, reworking the idea until thought feasible, based on the limited knowledge at hand.
  3. Product Manager/Owner develops business rational including the risks based on limited knowledge.
  4. Product Owner and Development collaborate to create the Business Canvas. You might consider using Ash Maurya’s Lean Canvas or Roman Pichler’s Product Canvas and Vision Board.
  5. Product Owner and Development collaborate to validate the Customer Problem and Solutions with customers through interviews and user testing. (Remove any Canvas entries that failed validation. Might need to go back to step 1.)
  6. Product Owner and Development provide an initial estimate. We’re looking for the ballpark, order of magnitude type estimate here e.g., 6 weeks or 6 months?
  7. Present Business rational and Canvas to business stakeholders for approval and funding.

Establishing preliminary understanding

The Product Manager’s product feature idea is now on the product roadmap (or equivalent). Depending on your business’s average lead time for work all the following steps could occur over the course of months or in rapid succession. My own experiences had roadmap items identified up to a year before the project, not very timely for customers but there are other factors at play including priorities, competition, and ‘hunches’ from the executive team.

These few steps are for illustration purposes and may not be what your team wants or even needs so feel free to modify for your specific needs. These steps will probably be done once. However, depending on the timing, may need to be revisited if the Product Owner and Development architect determine the data gathered has gone stale.

  1. Create one epic in Jira for one idea or feature. Most people use a tool rather than a big wall these days but if you have the wall space and an enthusiastic Scrum Master, by all means use a wall to define the high level projects.
  2. Development architects do initial technical scoping and high level design or impact mapping on current architecture. Unless you’re contemplating a new product, this will be based on the product’s current technical foundations and platforms.
  3. Full development team discusses the problem and possible solutions (non-technical). This is with a larger group of people using validated feedback from customers about how they envisioned their problem being removed from the user perspective. This serves as the baseline for UX designs. The discussion stays at the ‘what’ level but the full team might have something to say about feasibility and sizing.
  4. Full team provides updated estimates for Product Owner.
  5. Create the paper or wireframe UX designs & validate with customers.
  6. Development team (developers, UXD, and testers) along with Product Owner to define or confirm their collective understanding of what a ‘sprint ready user story’ is i.e. they define the Definition of Ready.
  7. Full team provides an updated estimate for the Product Owner.

The value to the business achieved during the above steps is to develop a good high-level understanding of all the work necessary for the initial epic user story. The team does a couple of estimates so the Product Owner can determine if the feature is still economically feasible. You’ll note customer involvement, looking at display mockups. The ideal situation is the customer finds that only a portion of the proposed work is necessary. The Product Owner and Development team keep focus on satisfying the customer in order to achieve a business goal.

On-going backlog grooming

This section details the steps for mainstream backlog grooming that gets repeated until a story is actually in a sprint. Most of these steps will be familiar. The full development team is ideally one Agile Scrum team but if there are several teams working a product, the grooming session should include those teams likely to work the stories. With a large number of teams (> 3), the LeSS framework, by Craig Larman & Bas Vodde,  suggests doing the grooming sessions in stages:

  • Overall Product Backlog Refinement (shared among all teams)
  • Team-level Product Backlog Refinement
  • Multi-team Product Backlog Refinement

 

  1. Full development team, using UX and architectural designs, begins breakdown of Epics into smaller stories using the Definition of Ready (DoR) guide the team established in the previous section.
  2. Product Owner and Development team continue to prioritize stories based on customer/business value but taking into account any implementation concerns or risks.
  3. Each user story is reviewed starting with those at the top of the backlog. Every user story is accompanied by notes, acceptance criteria, and estimates using the DOR as guide. If the story can be associated with a step in the ‘customer journey’, that would be a great help for stakeholders toward understanding the work.
  4. Product Owner and Development team review & discuss each story including those that are marked ‘sprint ready’. For stories not ‘sprint ready’, discussions on how the story could be implemented, could be tested, the customer value, and discuss compromises as necessary. ‘Sprint ready’ stories are checked that nothing has change that could affect the team’s understanding of the story or its priority.
  5. Again prioritize stories based on costs and customer / business value
  6. Check that all Epics and UX designs are covered with stories and have been prioritized.
  7. Make stories sprint ready and keep anyone who’s interested informed. My experience is most managers will not be looking through tools on a daily basis to determine progress. But being transparent is critical and using a big wall in a conspicuous location will provide the necessary details to management. If you have a ‘story wall’, you can use colored stickers to indicate status of stories i.e. sprint ready.
  8. The last step of every grooming session will be to again review the estimates and priority of the stories. Always check  the most valuable work is top-most on the product backlog.

The desired outcome of these sessions is:

  1. Big stories are split
  2. Stories are estimated
  3. Stories are well understood by the team(s) likely to implement them
  4. Stories are made ‘sprint ready’ based on the team’s Definition of Ready

Summary

In my experience, the amount of time needed between roadmap item to having a couple sprints worth of ‘sprint ready user stories’ is about 4 weeks calendar time, assuming development teams are busy doing sprint work as their primary activity. This provides time for any proto-typing, UX design, additional customer/user interviews, and getting input on marketing, sales, support, or other business concerns that could affect implementation choices. This could take a few days if done by an experienced project team in a full-time workshop.

Agile Product Backlog Grooming Reduces Risk

Agile product backlog grooming is a development team and product manager/owner activity that removes the necessity of massive up-front planning. Backlog grooming is also a key risk reduction activity for an Agile project. The risks reduced or eliminated can include feature dependencies, costs, schedule, building the wrong product, knowledge, feasibility, and capability.

With Waterfall projects, there’s a great deal of up-front analysis of requirements and locking down scope from which cost and schedule are derived. There’s no need to ‘groom’ these requirements throughout the project because they’re not meant to change. Product backlog grooming is a frequently occurring process in Agile projects for the simple reason that Agile projects do not do full up-front requirements analysis. With Agile, the assumption is we focus on the value delivered to the customer and anticipate the customer changing requirements as their business world changes and evolves. Agile caters to the dynamic customer and business while Waterfall works really well for customers whose world changes very slowly if at all during the lifetime of a project.

In anticipation that some of the up-front analysis of requirements will be wrong, the Waterfall project manager puts in a great deal of effort to define and manage the risks associated with locking down scope so early, often times before people in the project know what they’re getting themselves into. This is a good thing because no one can know everything up-front.

Backlog grooming

With Agile, there is no pretense that we know everything. In fact, the Agile project team goes into the project knowing that they know very little of the details. For example, a typical Agile project might know enough to plan for the next 2-3 sprints (6-weeks if doing two-week sprints). Scrum defines an activity call ‘Product Backlog Refinement’, grooming by any other name, which is an ongoing process conducted by the Scrum team to add details, review, refine, estimate, and order the user stories in the backlog. While the Waterfall project has a risk registry and an ongoing risk management plan, Scrum involves the Scrum team in backlog grooming as a key risk reduction activity. These risks include:

  • feature dependencies – Scrum teams will try to make stories independent but this is a goal, not the reality. Implementation dependencies will exist at times and through the efforts of backlog grooming, these dependencies are identified. Once identified, the development team and product manager can order the backlog taking these dependencies into account
    costs – grooming can reduce wasteful work being prioritized too high. The scrum team combs through the backlog looking to keep those stories customers are willing to pay the most for near the top. Grooming keeps those stories that make achieving business goals and customer goals at the top while placing stories about, lets say, place settings on the titanic, at the bottom or removed entirely.
  • schedule – most projects work to some schedule and grooming helps keep focus on those stories that will make your project a success. Schedules might be tied to sales cycles, business cycles, customer deadlines, or events. The goals for these scheduled dates are usually agreed to by the teams but based on the available knowledge when the commitment was made. Backlog grooming can help keep the biggest bang stories, those stories that provide the greatest contribution toward the goal, at the top even as more knowledge is gained.
  • building the wrong product – backlog grooming asks if the stories in the backlog are what the customer needs so business goals can be achieved. As the project progress so does the likelihood that customer wants and needs change. Backlog grooming sessions check the staleness of information used to prioritize stories. If it’s been awhile since the team spoke with customers or customers have been absent from sprint reviews, then an action from a grooming session could be to re-validate a customer problem or solution with customers.
  • knowledge – product backlogs usually have the structure where large stories sit near the bottom and progressively smaller stories populate the backlog until the top 2-3 sprints worth of stories are small, ‘sprint ready’ stories. The process of taking larger stories and breaking these down to sprint sized stories never ends and will transcend projects. The process of breaking down stories involves digging out more details. These details can reveal a knowledge gap exists that needs to be closed before a story can be worked. Unless the story came up from the depths unexpectedly, there will always be time to recognize the knowledge gaps and find the knowledge either through training or getting a temp specialist.
  • feasibility – like the knowledge risk, feasibility can be handled before actual time to implement the story. When following a routine groom paradigm where large stories are broken down over time, it will be easier for the development team to provide earlier analysis of feasibility. The first analysis of feasibility would normally occur during the ideation phase, when a feature is added to the road map. However, the difference between “we should be able to do this” and “we know we can do this” can potentially put a company out of business.
  • capability – this ties in closely with the knowledge risk but is broader than team skills and capabilities. This includes things like test environment, development environment, build environment, customer access, and stakeholder involvement. Again, as larger stories are broken down during grooming, the team assesses the these needs to make implementation and delivery of the story successful.

Things that impede grooming sessions

Development team doesn’t feel responsible for the user stories.

“writing and rewriting user stories ain’t my job.”

I think this will be the impediment most often seen slowing down grooming sessions. I found that once development got used to their traditional roles, it was hard to get the developers on board with writing and rewriting user stories. Although the product owner remains accountable for the order of the backlog, they are not necessarily solely responsible for the stories.

All I can advise is setting the expectation that as members of the Scrum team, they all equally share the responsibility for the product backlog and its contents. This is best if re-enforced by management. The other factor will be time, it may take several months for the full team to accept this new responsibility. The Scrum Master can use the retrospectives as a vehicle for improving the grooming sessions. For example, can the bigger stories be broken down by anyone else other than the product manager? Someone in the team will suggest they can help the product manager. This is a very positive step forward. A note of caution: developers might try writing user stories that are very technical in nature.

Product manager not giving up control of user stories

I found that this will happen but goes away rather quickly as it’s the development team that needs good stories so they can attain a good understanding of the work required. This follows these three steps:

  1. Product manager controlling all aspects of user story writing
  2. Development team is in a struggle with the product manager over meaning and acceptance of user stories
  3. Product manager makes a business decision to allow the development team in on writing stories and reducing the amount of time explaining what the stories mean.

Backlog grooming sessions not a team event 

How much fun is backlog grooming for your Scrum team? Are you part of a team or scrum master of a team that goes to grooming only to agree with whatever the senior developer or team lead says? “Does everyone agree?” “Yes.” [Audible ‘TICK’] Maybe is was better when we did waterfall!?

It’s important that the first backlog grooming sessions be well facilitated so the team can be drawn in to the backlog and backlog grooming process. Going around and asking each individual what their opinion is, to explain their understanding of the story, and to describe what the high level design is will help. Some people will take to this quickly while others will take several grooming sessions to draw them out. Don’t give up but continue the facilitation until participation becomes natural for the team.

I’ve also seen where having the team lead or team manager as part of the team can stifle participation at grooming sessions. Providing coaching to the manager to encourage a ‘servant leadership’ approach is of inestimable value to creating a self-organizing team. This has worked great in the past and was the subject of a talk I gave at Scrum Australia 2016.

6 Steps to Prepare for a New Agile Project

In my previous post, 15 Steps to Agile Project Planning Success, I focused on the Inception workshop aspect of Agile project planning. Here I’d like to step back a bit and look at the steps and events that occur before the Inception workshop in a little more detail.

As Scrummaster or Agile Project Manager, you want your Scrum team to be successful and you’re probably willing to do most anything to see that it happens. One way to help the team be successful, and let the organization know what they can expect, is to do high level upfront planning.

The Scrum Guide gives lots of guidance on planning for Sprints, talks about Backlog Refinement in a side reference to planning, but doesn’t say anything about high level planning for the project. This isn’t the way it always was. Back in the 2010 version of the Scrum Guide you would have seen both Release Planning and Release Burndown charts. This was removed to highlight the fact that Release Planning isn’t necessary to do Scrum. It may not be necessary to do Scrum but hardly a business exists that doesn’t want some predictive means of future outcomes. This is where the Scrummaster or Agile Project Manager steps in and help make the Scrum team be heroes.

Any software project starts with a business need or goal. This might be playing catch-up with the competition’s latest release, customer feedback for product improvements, an innovative idea, a business’es desire to grow, or simply someone’s idea of what to do next. Some of these project ideas might be successful, some might be failures but all of them can benefit from planning.

Below are 6 simple steps to initiate your Agile project.

  1. Validate the problem and the solution
  2. Validate the feasibility of the solution
  3. Identify the Scrum team(s)
  4. Identify your key stakeholders
  5. Identify your key customers
  6. Create the measures for the project

1. Validate the problem and the solution

The first thing that should happen is validation of the problem your product has, and the solution. This part of preparing for your Agile project is the first instance where you hope to fail fast. Through validation you could easily discover your insanely great product idea is merely insane.

The problem is tied to the business goal the company wishes to achieve. For example, the business goal is to signup more subscribers. You theorize customers aren’t signing up because it’s slow and hard. Fixing this will result in more customers signing up because we’ll make it faster and easier to sign up.

This is also where you hope to fail. Failing here costs practically nothing compared to the cost of building an unwanted product. This step would generally be initiated by the Product Manager but involves development and the Scrummaster or Agile project manager. It may also involve other departments in the business like Sales and Marketing.

The easiest way to validate problems and solutions is through conversations with customers and users. Does your hypothetical problem and solution resonate with customers? If 2 out of 10 potential customers like your idea, that’s an interesting statistic. If 8 out of 10 potential customers love the idea, this is very meaningful and you are much more likely to have something worth pursuing.

2. Validate the feasibility of the solution

The problem and solutions have now been validated with customers and users. You now need to confirm if the company has the knowledge and resources to fulfill what the customers need. The development team validates that technically, the solutions can be done. The development team also confirms if they possess the required skills to solve it. This step will require some initial estimates made by the development team to check that the costs don’t exceed the potential benefits. Ideally, the Scrummaster and Product Manager have brought in at least one member of each team that could potentially work the project to provide these rough estimates.

This step is done as a research and prototyping exercise but needs to answer these questions:

  1. Can the work be done?
  2. How many teams will be necessary?
  3. What skills are currently available?
  4. What skills need to be learned?
  5. How long would it take to do the work?
  6. What does the high level architecture look like?
  7. What will I get at the end of the project?

If this is a massively large project requiring 100’s of Agile teams, the Product Manager, with the help of the most experienced developers, break down the work into something like “10 team” increments. For example, creating a product like Microsoft Office might require this to be broken down into smaller, more manageable chunks. These might be, Common Infrastructure, Word, Powerpoint, Excel, Outlook, etc. The goal of breaking down the work is so a small pod of teams (e.g. 10 teams) can work independently of any other pods if possible. Identifying independent streams of work will likely influence release planning later during the Inception workshop.

A note of caution on the estimates. If the estimate is 60 person months, that doesn’t mean 60 people can do the work in a month. The group working the feasibility of the solution should consider the maximum number of people who can work concurrently on the project. This means that special attention be given to any dependencies. In the group’s thumbnail architectural sketch they will need to factor in both serial and parallel development efforts before giving high level estimates.

3. Identify the Scrum teams necessary

Following on from step 2 above and assuming you haven’t failed the project based on step 2’s answers, the Scrummaster and Product Manager, along with development team leads, determine specifically which Agile teams are needed. This will take into account availability and skills but may also identify any necessary training. Although a project may not start with a full complement of teams, it is important that all teams be brought on-board for project visioning and the Inception workshop events.

4. Identify your key stakeholders

Successful projects depend upon a variety of people. The Scrummaster and Product Manager need to actively determine who their key stakeholders are and what their influence and interest in the project is. These stakeholders, usually part of the business hierarchy, have goals that they hope the project fulfills. You need to know this and actively demonstrate progress toward achieving their goals. You also need to identify any contradictory goals between stakeholders and resolve them now. These can’t be left to fester because they could eventually derail the project.

To resolve any conflict you’ll need to reestablish the business goal(s) the project is meant to meet. This will require the stakeholders and you to review the business goals, and how the project intends to meet them. A frank and open discussion will bring out the conflicts.  Ask the stakeholders to outline what they feel the goals are or should be. Compare those two opposing sentiments, and then explain how elements of each contribute to the business goals. Facilitate this meeting to achieve a lasting compromise of the details necessary to achieve the higher goals.

5. Identify your key customers

Identify your key customers or customer segments. You will need to figure out how to involve your customers in the project and keep them involved over the lifetime of the project. Put together plans to get customers to your sprint reviews, set up A/B testing strategies, or conduct user testing. Getting and keeping your customers and potential customers engaged will be a large factor in the projects success.

The Scrummaster and Product Manager will need a comprehensive plan to involve your customers. Some ideas could be:

  1. Create a project/product blog where status information can be radiated
  2. Get out of the building and meet potential customers at lunch. Show them your evolving product or website and gather their feedback.
  3. Invite customers to your sprint reviews.
  4. Conduct product reviews at a customer’s office if possible.
  5. Offer trial periods or beta products with opt-outs.

6. Create the measures for the project

The Scrummaster and Product Manager will need to know what success means for all stakeholders, customers, and other business entities including development. This is a project level definition of done and key tracking measures for each. This starts with the business goals and business requirements. A possible definition of done for a project could be:

  • Business goal of “increase males aged 25-40 sales by 35%” has been achieved
  • Customer feedback indicates the landing page is now appealing to both men and women shoppers
  • Business goal of a “12% increase of revenue” has been achieved.
  • Customer Net Promoter Score is above 73
  • Project team engagement score maintains a 90% or greater score

The definition of done should be as specific as possible to goals and customer problems but should not be so specific that developers and innovation are stifled. Your company should be encouraged to keep to higher level goals and outcomes and trust the teams to achieve these goals in the best way possible.

Once the business has arrived at a definition of done, this does not change. Changing the definition of done for the project might become very tempting to management as the end date nears. It should not be impossible to change this, just very, very hard.

Using the definition of done for the project as a guide, begin creating specific measures to track progress. You can start with the business goals. Take each business goal is break these down to the constituent components. Each component needs to be weighed for importance and prioritized. This is accomplished with select key stakeholders, customers, developers and anyone else who can help. The reality will be that people will find components of a goal that aren’t really necessary to achieving the goal. It becomes import to segregate the “wants” from the “needs”. You can use MoSCoW as a prioritization technique.

The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. Source: Wikipedia

Any details may be revisited & revised during the Inception workshop. What you don’t want to redefine is the project’s definition of done unless business goals become obsolete.

As an example, the high level measure for converting the landing page might be “how often male customers aged 25-40 click through from the landing page.” However, you’ll also need to include measures of all your other customer segments to check that you’re not losing their business in the process.

Plan and conduct the inception workshop

At this point, the Scrummaster (or Agile Project Manager) and Product Manager should be ready to run the Inception workshop. Be prepared to inspect the findings and adapt as needed. The best planning is flexible and welcoming of new found information, even if it reverses your thinking.

See, 15 Steps to Agile Project Planning Success, for more on running an Inception workshop.

Summary

Planning is important for project success but planning can’t guarantee success. One advantage to Agile planning will be a certain looseness and openness that can allow plans to change as more is learned. The more ridged the plan the more likely you will be to follow it even when good sense tells you not to. The point of the above steps is not to guarantee success but to find failure points faster.

A good plan is about removing or mitigating risks. Following these steps can help reduce risk.