Where should one start when kicking off an Agile transition?
Usually, tools and processes are smallest the common denominator among all participants, as they are at the core of the grand scheme of Agile things.
It is a rare occasion that one would start from scratch with a brand new team without an existing product, probably even in a more or less nascent organization such as a startup.
In most cases, an existing product delivery organization with available products and services will go Agile. In this case, turning attention to the available product backlog is a pragmatic first step. The following process describes what aspects need to be attended to in order to optimize the outcome.
Refinement of the Existing Product Backlog
Starting the Agile transition with an extended product backlog refinement session has also proven to be an effective way of coaching a new team. Ceremonies, practices, and artifacts, as well as Agile principles, can be introduced “on the job,” so to speak, using break-out sessions whenever required.
Such an initial refinement workshop may require—depending on the maturity and size of the organization and its products—several hours or even several sessions.
As far as the kick-off in general is concerned, the product backlog is an interesting artifact as it provides a deep dive into the product delivery organization’s history. Almost like an archaeologist digging through layers of an ancient civilization, you can identify organizational debt, process insufficiencies, problematic product decisions, and other anti-patterns by sifting through the backlog.
Product Backlog Anti-Patterns
Some typical anti-patterns that can be found in legacy product backlogs are:
- The product backlog is structured in a Waterfall manner:
- There are no team projects, only projects spanning the whole organization or division to ease the reporting process. (The “70% finished” syndrome.)
- The product backlog is a long, unstructured list of ideas, features, bugs, minor technical tasks, change requests, and epics—and thus practically not in a state anyone could effectively work with.
- The prospective value of tasks is not reflected by a ranking, as prioritization is due to the sheer size of the product backlog no longer an option.
- There is no consistent quality in building user stories, i.e., based on Bill Wake’s INVEST principle.
- There is no “Definition of Ready” applied to user stories.
- A significant proportion of user stories consist of barely more than a headline without any additional information on the “why” or “how.”
- User stories are being kept in the product backlog for months without being improved over time, accomplished, or archived for lack of value.
- Product backlog items are being created directly by everyone, i.e., stakeholders, and not just the product manager or Product owner.
- Product managers already create (sub-)tasks and assign them directly to developers.
How to Apply Structure to the Product Backlog
How does one get from potentially hundreds of unstructured “user stories” hidden in the legacy product backlog to a valuable product backlog in an Agile sense?
From my experience, there is only one way to achieve this: Inspect each item in the legacy backlog and decide collaboratively with the whole team whether the issue is worth working on or not.
A process for this procedure may look like the following:
- Step 1: Identify all relevant tasks for the newly created team—probably distributed across several projects—and migrate those deemed valuable to the team’s new project.
- Step 2: Kick off the refinement process by creating shared understanding on:
- The purpose of the team’s product backlog in general.
- The idea that the product backlog isn’t supposed to be a bucket for each and every idea.
- The idea that a valuable product backlog covers rarely more than a period of maybe 6-8 weeks.
- Step 3: Introduce the product backlog refinement process. Explain the benefits of dividing the original Scrum sprint planning ceremony and creating a separate backlog refinement ceremony, which are:
- To defuse the sprint planning meeting in the first place. (Who wants to spend eight hours on that?)
- To be more flexible responding to change while working on user stories.
- To provide the product owner with better options to answer questions from the Scrum team in a timely manner. (It’s easier to do that once or twice a week than every two weeks, for example.)
- To create a smooth process that includes the graphic and UX designers. (Creating deliverables collaboratively becomes thus much simpler.)
- Step 4: Introduce the Scrum team and the product owner to the best user story practice, such as Bill Wake’s INVEST principle. Visualize the sweet spot of value, usability, and feasibility. The team needs to embrace the idea that a user story is primarily a token for discussion.
Step 5: Create with the Scrum team and the product owner their version of a “definition of ready.”
- Step 6: Kick off the estimation process by introducing the “estimates are nothing, estimating is everything” idea:
- Estimating is all about knowledge transfer and creating a shared understanding of why a user story is valuable and how it might be realized.
- Estimates are a metric for the Scrum team.
- Estimates are defined in relative sizes—T-shirt sizes, Fibonacci figures—not man-hours.
- There might be a discussion ahead with the perception of velocity by stakeholders. It might trigger attempts to micromanage the team, or determine delivery dates. (Read more: Scrum: The Obsession with Commitment Matching Velocity.)
- There are useful Agile metrics available. (Read more: Measurement For Scrum – What Are Appropriate Measures?)
- Estimation poker should be used on all required stories.
- Step 7: Explain how dealing with technical debt fits into the game so that the Scrum team ensures that a fair share of each sprint’s resources are allocated to refactoring.
Tip: When there is (an urgent) release scheduled in the near future—say in 8 to 12 weeks—that needs to be met and the Scrum team is already on a tight schedule, the initial backlog refinement will likely be not ideal from a Scrum master’s perspective.
However, insisting in such situations on a textbook approach—which inevitably will result in a delay of the release—is likely to cause serious communication problems. The management, and particularly those managers and stakeholders that might have opposed going Agile in the first place, might consider their worst fears confirmed. Be pragmatic and think twice before picking your battles.
Kicking off the Agile transition in an organization with an existing product backlog by a thorough refinement session is a proven technique. It is a good exercise to train the new Scrum team on the job in artifacts, ceremonies, and Agile principles.