Tag Archives: variation

It’s not uncommon for me to visit a new client and to discover that the scrum teams change frequently, sometimes after every single sprint. Changing the team composition too frequently is undesirable for the individuals and the organization. To flourish, teams need stability. With markets, requirements and technologies frequently changing in an agile world, a stable scrum team provides security and continuity.

To create stable scrum teams, follow these recommendations:

First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role in order to develop a great product. Having the right individuals on board is most likely the biggest success factor for any development effort.

Second, minimize any changes to the Scrum team within and across releases. It takes some time for a group of individuals to become a true team – a tightly knit unit with members that trust and support each other and that work together well. Changing the team composition makes this teambuilding process start all over again and, as a result, productivity and self-organization suffer. Avoid loosing team members while a release is being developed. A good time for people to leave and new members to join is after the release of a new product version. But ensure that the majority of the team members continue to work on the product to avoid loss of information, defects and delays.

Last but not least, establish a long-term partnership between a Scrum team and its product; every product should be developed by one or more dedicated teams. This not only facilitates ownership and learning, but it simplifies the allocation of people and resources.

The product owner should always be a permanent member of the Scrum team. This allows the individual to manage the entire product lifecycle, from gestation to its discontinuation. It also encourages balancing short-term wins with long-term success.

Find out more about employing stable teams by reading my book Agile Product Management with Scrum or by attending my product owner course.

Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. It’s time to put any over-weight product backlog on a diet making it lean and concise. This blog posts continues the discussion of making a lean product backlog by limiting unnecessary variation and preventing overburden.

Limit Unnecessary Variation

Variation, also called unevenness, prevents a smooth flow of work. While not all variation in the product backlog is bad — the size of its items should vary depending on their priority to minimise waste, for instance — reducing unnecessary variation helps create a lean backlog and a lean workflow:

Standardise the techniques for describing product backlog items. Choose user stories to capture functional requirements and operational qualities such as performance and robustness requirements, for instance. Agree on a common way to describe usability requirements such as sketches, wire-frames or mock-ups.

Use a sprint goal. The sprint goal summarizes the desired outcome of the sprint, and moves the Scrum team a step closer toward the release of the product. A shared sprint goal ensures that everyone is working toward a common goal. It minimises variation by limiting the type of requirements worked on in a given sprint, for instance, by choosing items from the same theme. This facilitates close teamwork and can increase velocity.

Ensure that the high-priority items have roughly the same size and favour small items – items that can be transformed into a part of the product increment within a few days. This reduces variation, improves the progress tracking within the sprint, and prevents defects by allowing the product owner to provide just-in-time feedback on the work results. Note that this approach works best when the team uses agile development practices including story-driven development.

Create a steady cadence by using fixed-length releases. Timebox your projects: Identify the window of opportunity based on the product vision and the product backlog, and freeze the release date. Take Salesfore.com, a leading provider of on-demand customer relationship management services. The company releases a product update every four months. As a consequence, Salesforce.com experienced an amazing increase in the number of features delivered while drastically reducing its lead-time for new functionality. Note that a fast, steady cadence supports other measures including minimising the inventory in the product backlog.

Prevent Overburden

As long as people work crazy hours, and as long as projects and teams are overwhelmed by the amount of work, the removal of waste and variation is ineffective. Waste and variation are likely to creep back in unless we limit the amount of work to the capacity and capabilities of the organization. Let’s assume we try to eliminate defects but the project still suffers from overburden. Chances are that quality problems reappear since the project members still feel pressured and are overworked. In fact, overburden is a major source of waste including work-in-progress, waiting and delays, task-switching, and defects.

To eliminate overburden, let the product backlog evolve based on customer and user feedback. View changing requirements as a competitive advantage and leverage the feedback together with the project progress to decide which functionality is implemented. Encourage the team to pull only as many items into the sprint as they can transform into a product increment in a sustainable way. Ensure that the high-priority items are ready: They should be clear, testable and feasible. This avoids that the team overlooks tasks and pulls too much work into the sprint. And last but not least, make high-priority items small. This allows the team to optimise its work utilisation. It also avoids the danger of missing tasks – which is a common issue with large stories.

Find out more

Find out more about working with the product backlog effectively in my book Agile Product Management with Scrum. Attend my lean training course to fully understand how product owners can benefit from applying lean techniques.