User stories are probably the most popular agile requirements description technique. A story contains a name, a brief narrative, and acceptance criteria. It’s comparatively easy to write, decompose, and refine user stories. But writing good stories can be hard. The following ten tips help you tell powerful stories.
Find out more about user stories in Mike Cohn’s book User Stories Applied: For Agile Software Development (Addison-Wesley, 2004). Learn to write great stories in my user story writing workshop and how to work with stories on the product backlog in my Scrum product backlog training.
It’s not uncommon for me to visit a new client and to discover that the 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 team provides security and continuity.
To create stable 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.
Decomposing User Stories
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 the backlog lean 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.
“We have 12,000 stories in our product backlog. How can we best groom it,” I was recently asked. Trying to deal with a huge product backlog is more common than we would like to think. 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.
Think Lean
Lean thinking aims to create a smooth, levelled flow of work by removing waste, minimising variation and avoiding overburden. Waste includes inventory and work-in-progress, defects, delays, and unused employee creativity. Examples of variation are frequent changes to the team and varying release cycles. Overburden occurs when people and resources cannot cope with the workload placed on them. If we want a lean product backlog, then it should contain as little waste and variation, and cause as little overburden as possible. This post focuses on eliminating waste. I will discuss minimising variation and avoiding overburden in a future post.
Eliminate Waste
Waste consumes valuable resources and makes it harder to focus on what’s important. To remove waste in the product backlog, reduce the inventory the backlog holds, avoid overproduction and minimise defects, handoffs and wasted creativity, as I explain in more detail below.
Reduce the inventory in the product backlog: Minimise the amount of detailed product backlog items and only include items in the backlog that are essential for creating a successful product. Ensure that just-enough high-priority items are detailed just in time for the next sprint planning meeting. As a consequence, product backlog items are progressively decomposed and refined – from sprint to sprint. Lower-priority items stay coarse-grained and sketchy until their priority changes.
Avoid overproduction – providing more functionality than users and customer need. Focus on the minimum functionality necessary to bring the product to life, and only list truly valuable items in the backlog. Have the courage to remove all other items from the product backlog. This keeps the product backlog concise and the Scrum team focused. If an item becomes important for a future version, it will re-emerge.
Minimise defects, handoffs and unused creativity by involving the team members and the stakeholders in grooming the product backlog. Jointly discovering and describing product backlog items avoids handing off requirements to the team. It ensures clarity of the requirements thereby reducing defects; and it leverages the creativity and knowledge of the team members and stakeholders. Jointly prioritising the product backlog ensures that technical risks and dependencies are accounted for. Problems consequently surface early, which prevents defects at a later stage of the project.
You can find out more about working with the product backlog effectively in my book Agile Product Management with Scrum: Creating Products that Customers Love or by attending my lean thinking course that teaches product owners how to leverage lean techniques.
Scrum has a strong product focus; it knows a product owner, a product vision, a product backlog, and a product increment. But what is a product?
The answer to this question can be tricky. Take the attendees of a recent product owner workshop I ran who found it difficult to agree on what their products are. Another client of mine was completely project-driven before using Scrum; short projects often updated a number of application and systems. When asked about their products, developers would answer, “Oracle,” or “Websphere” rather than referring to the software they created. And another company I worked with had more than 20 different definitions of the term product.
So what is a product? I like to think of a product as collection of attributes (or features) that address customer or user needs thereby providing value. A good first step in identifying products is to ask, “Who benefits from our software? Who purchases and who uses it?” and “What value does the software provide?”
A product is developed using a project, which creates one or more releases and results in a new product version, as the following sequence shows:
Customer and user needs
→ Are addressed by a product
→ Has a version
→ Is developed by a project
→ Creates one or more releases
Products are means to an end – to meet customer and user needs. Projects and teams serve to bring the next product version to life. Understanding which products an organisation develops is the prerequisite for achieving product success. It enables longer-term thinking and finding the right people. Only if it’s clear what the product is can management find the right product owner and can the right people be invited to join the development effort.
So think products. Not projects, not teams, and not components. Focus on what ultimately counts – to create a great product to help customers and users – and organise accordingly.
Prioritisation requires us to decide how important an item is. If everything is high priority, then everything is equally important. This means in effect that nothing is a priority, so there is only a slim chance of delivering what the customer really needs. Prioritisation is part of product backlog grooming, and it directs the team’s work by focusing the team on the most important items. It also freezes the backlog contents progressively. As items are detailed according to their priority, flexibility is built into the process and allows delaying decisions about the lower priority items, buying the Scrum team more time to evaluate options, gather feedback from customers, and acquire more knowledge. This ultimately results in better decisions and a better product. The reminder of this posts explores four useful factors to prioritize the product backlog: value; risk and uncertainty; releasability; and dependencies.
Value
Value is a common prioritisation factor. We certainly want to deliver the most valuable items first. But what makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. The Scrum team either de-prioritizes the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the Scrum team focused. If the item is important for a future version, it will re-emerge.
Risk and Uncertainty
Risk is an intrinsic part of software development; no product can come to life risk-free. Correlated with risk is uncertainty. The more uncertainty there is the riskier the project is. Because risk and uncertainty influence product success, uncertain and risky items should be high priority. This accelerates the generation of new knowledge, drives out uncertainty, and reduces risk. If the Scrum team, for instance, is unsure about some aspects of the user interface design, then the relevant design options should be explored and tested by gathering feedback from customers and users. Tackling uncertain, risky items early creates a risk-driven approach that may enforce early failure. Failing early allows the Scrum team to change course while there is still the opportunity, for instance, to modify the architecture and technology selection.
Releasability
Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If the Scrum team is uncertain about if and how a feature should be implemented, then early releases can answer this question. Being able to release product increments early and frequently should therefore influence the product backlog prioritisation. Each release should provide functionality that is useful to customers and users and that generates the desired feedback. Note that it’s usually not necessary to fully implement a theme; a partial implementation is often sufficient for early releases.
Dependencies
Weather we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even non-functional requirements. And if several teams work together, dependencies between them can influence the prioritisation. Dependencies restrict the freedom to prioritize the product backlog and influence the effort estimates; the item others depend on has to be implemented first. You should therefore try to resolve dependencies whenever possible. If that’s not an option then the dependencies are likely to influence the product backlog prioritisation. Two dependent items may have to be implemented in the same sprint, for instance.
Find out more about how to prioritise your product backlog in my book Agile Product Management with Scrum: Creating Products that Customers Love.
The product backlog is a beautifully simple artefact – a prioritized list of the outstanding work necessary to bring the product to life. In reality, many product backlogs are large and unwieldy – rather than simple and concise. If you regularly groom your product backlog but still struggle with its size and complexity, then you may have a backlog that contains items from more than one product: requirements describing different products but kept in the same backlog. This may be due to one Scrum team developing several products concurrently or creating a new software system while maintaining its predecessor.
If that’s the case, break up your product backlog and create a separate backlog for each product. This will not only result in smaller backlogs that are easier to groom. But it will allow you to better prioritize which product takes priority – the development of the new software or the maintenance of the old system, for instance – thereby making the corresponding portfolio management decisions explicit.
You can simplify your product backlog even further by focussing on the next product version and by minimising the number of items describing future releases. As the future is uncertain and markets are likely to change, carrying many future requirements does not only bloat your product backlog; it is wasteful and makes it difficult to adapt your product to the market response. Have the courage to weed out items that are not essential to creating the next product version. Simplify, prune, and strive for order. Discarded items will come back to you if they do become relevant in the future.
A little while back I asked you to share a product owner story to win a copy of my new book Agile Product Management with Scrum. I have finally come round to pick a winner: Steen Hulthin Rasmussen.
Well done and thanks to everyone for participating!
Pull processes do not only play an important role in lean approaches such as Kanban, they are also fundamental to Scrum: Applying the framework generates a pull process where teams pull work from the product backlog into the sprint. Understanding what a pull process is and how it works helps you apply Scrum and Kanban effectively.
The easiest way for me to illustrate the difference between push and pull is to evoke a childhood experience you may share with me: drying the dishes. I vividly remember being called into the kitchen after Sunday dinner where my mum had already piled up the clean wet dishes. Even though I would frantically try to reduce the size of the pile in front of me, I always ended up finishing off the job long after my mum had retreated to the living room together with the rest of the family.
Now imagine running cleaning and drying the dishes in pull mode. The first thing my mum and I would do is to agree on a small buffer of clean wet dishes, say three. I would then wait for my mum to populate the buffer. As long as the buffer is full, my mum is not able to clean any new dishes. Only once I have started drying one of the dishes, she would clean the next dish.
Establishing a pull process changes how work is carried out: It closely links formerly disjointed process steps; problems and impediments now surface quickly. A pull process eliminates waste such as partially done work (also called work-in-progress or WIP). What’s more, it creates a sustainable pace by avoiding overburden: In Scrum, the team determines how much work they can pull into the sprint and hence manages its own workload. In Kanban, WIP limits ensure that demand is matched to capacity.
Be aware that establishing pull usually involves disruptive change. It it requires that the people carrying out the work take on ownership and are empowered. Work can no longer be pushed onto anyone. It now has to be pulled along.
Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver bullet is an easy trap to fall into, as the following story illustrates.
I was recently asked to help a client apply Scrum to its localisation work to make the progress of work items more transparent. The client had already used Scrum in product development for some time, and spreading it to other business areas seemed like the next logical step. To better understand the client’s context, we held a workshop and performed a value stream analysis – walking through the entire workflow from issuing a localisation request to delivering the finished piece of work. Visualising the process showed that two steps in the process caused problems including delays and defects. But unfortunately, the workshop participants were not able to back them up with empirical data.
Reflecting on the value stream map, I was not able to see how Scrum could be effectively applied to the process. There was no team and no need for close teamwork; there was no product that could be built up incrementally – requests were worked on independently and concurrently by translators in different countries; the localisation backlog was neither dynamic nor made it sense to detail its items at different levels; and work was pushed from one step to another with the project manager chasing requests and individuals.
To help the localisation team better manage their work and collect important data such as where and when impediments occur, how long it takes to complete a certain type of localisation requests, we simplified the value stream map and created a simple Kanban board captured in a Google spreadsheet. The board itself does not improve the process at all but it provides a simple high-level view of the entire process visualising the progress of individual items. We colour-coded different request types and decided to mark blocked items in red. The team now has the right tool to collect the necessary data to quantify their problems and calculate the business impact. What’s more, the board makes it easier to manage the work thereby reducing the project management overhead and encouraging collaboration.
Once the data is available, it will help promote process improvements including changing the process from push to pull and increasing the stakeholder participation. Interestingly, clarifying the ownership of localisation requests will be fundamental to making significant progress – moving from handing off requests to close collaboration. But product ownership and the role of the product owner in a lean, Kanban-based context is the topic of a future post.
User stories and use cases are powerful techniques to capture requirements. Even though Scrum is agnostic about how requirements are described, user stories are becoming the standard way to express functional requirements on the product backlog. Before I explain why, let’s briefly reflect on what user stories and use cases have in common.
Both techniques put the customer or user at the center of the development effort. Use cases describe how a customer interacts with the product using one or more scenarios. A use case may consist of a short narrative or of several structured scenarios including main success scenario, alternative scenarios and failure scenarios. User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. Uses cases and user stories employ customer roles known as primary actors and user roles respectively. Both techniques can be applied at different levels of granularity: Use cases may be written as business or system level use cases. User stories may be formulated as epics, coarse-grained or detailed stories.
User stories are particularly popular on the product backlog for two main reasons: First, applying the technique is easy (but writing good stories can be hard). There are no complicated templates, no pre and post conditions, no triggers and exceptions to be specified. Since the barrier for writing stories is low, it’s easy to do it together involving the entire Scrum team. Second, decomposing stories is comparatively easy; large stories or epics are broken into smaller, more detailed ones over time to ensure that they can be delivered within a sprint according to the definition of done. Having worked with both user stories and uses cases in Scrum, I do prefer stories over use cases on the product backlog.
If you like to work with business use cases to create the product vision, then derive user stories from your use cases by splitting each use case scenario into one or more stories. The stories are then used to stock the product backlog. And don’t feel obliged to describe every single product backlog item as a user story. User experience requirements, for instance, are best captured using different techniques such as user sketches, storyboards, user interface navigation diagrams, and prototypes. These artifacts complement and elaborate the stories on the product backlog.
You can learn more about stories on the product backlog in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.
A recent posting on deutschescrum brought up an interesting question: How much visioning is necessary in Scrum? Even though I find it impossible to give a general, precise and accurate answer, there are two main factors that influence the time and effort necessary to create the product vision and the initial product backlog: the product’s lifecycle stage, and its complexity.
The younger a product is, the more visioning work tends to be required. A new-product development project may spend several weeks creating the product vision and carrying out necessary prep work such as creating prototypes to explore product design and architecture options. Contrast this with an incremental upgrade of a mature product that may only require a few days of visioning work. The same applies to complexity: The more complex a product is, the more visioning time and effort is usually necessary. Note that complexity comprises not only the internals of the product – its architecture and technology – but also the functionality provided.
When determining your visioning effort, avoid two common mistakes: Don’t rush into the first sprint without having agreed on an overarching goal, without understanding what the future product will roughly look like and do. At the same token, avoid overdoing the visioning work. There is no way to guarantee that the vision is correct, that the new product or next product version will be a certain success. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult; no market research technique can deliver forecasts that are 100% accurate.
I therefore recommend you keep the visioning time and effort to a minimum. Do as little as possible, but as much as necessary. To find the sweet spot, try the following: First, focus on the customer needs and the three to five top features of the product. Second, envision the minimum marketable product – a product with the least amount of functionality that still has a clear value proposition. Third, quickly implement the product vision and gather customer and user feedback on early product increments to validate and refine the vision. And last but not least, reduce complexity by creating a simple product – a product that is easy to use and easy to extend and maintain.
Find out more about visioning in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.
Share your favourite product owner story or tip and win a copy of my new book Agile Product Management with Scrum. Just reply to this blog post and add your story.
I’ll select the best story by 15 May 2010, and I’ll post a copy of my book to the lucky winner.
Software quality is often perceived as something the nerds should worry about. But it significantly impacts product success by affecting the following areas: customer satisfaction and brand value; the total cost of ownership and life expectancy of your product; and the product’s competitiveness as I explain below.
Why Quality Matters
Quality influences customer satisfaction and brand value. Only if the product’s functionality works reliably as expected will customers be satisfied and value the brand highly. Defective software does not only leave customers dissatisfied, frustrated or angry, it also damages the brand value. Think about the issues Microsoft experienced with Windows Vista. These contributed customers defecting Microsoft and to the company to discontinuing the Vista brand calling its next OS version “Windows 7.”
Quality impacts the total cost of ownership and life expectancy of a product. Getting software out of the door quickly with poor quality may achieve a short-term win but it incurs technical debt: The software becomes difficult to extend and maintain, as Ward Cunningham observed nearly two decades ago. This results in high cost and long lead times for new functionality. And software with poor quality often has to be replaced sooner rather then later resulting in a short life expectancy and a poor return on investment.
Quality affects the product’s competitiveness: To create a product that incorporates customer feedback on early product increment, to release software in response to the latest market development, and to bring new functionality to the market quickly is only possible if the product exhibits the right quality. Take the development of Google News, an application that aggregates news from around the world. Google used user feedback on early versions of the software and user requests for new features to determine which functionality the product should contain.
Compromising software quality means trading in short-term gains for longer-term growth cheating the company of a better, brighter future. As the product owner, you are first and foremost responsible for product success. Software quality should hence be a concern to you.
What Product Owners can do to Ensure Right Quality
There are many ways for a product owner to help get the software quality right:
Think products, not projects: A product owner should own a product and look after it for an extended period of time thereby managing the product’s lifecycle. A longer-term responsibility counteracts the temptation to compromise quality in order to get the next release out as soon as possible. It creates a desire for sustained success and it encourages long-term thinking.
Create a common understanding of quality. Make sure that a definition of done is available and apply it properly. The definition should clearly state the general quality criteria product increments must fulfil. It usually requires that a (potentially) shippable product increment is available at the end of each sprint: executable software that has been tested and documented and that could be released. As a consequence, quality assurance and control measures form an integral part of the development work—instead of being carried out at the end of the project as an afterthought. Be specific what tested and documented mean for your product; I have worked with teams that used metrics to refine and measure the quality criteria. As the product owner, you have to apply the done criteria to accept or reject work results when reviewing items; only work results that fulfil all the done criteria can be accepted. By enforcing the definition of done the product owner acts as the guardian of quality.
Minimise defects and unnecessary rework. Groom the product backlog together with the team and by be available to answer questions as they arise. With requirements emerging and changing, the product backlog needs continued attention and care. New items have to be captured, existing ones adjusted or removed. Items have to be prioritised and estimated; and the high-priority items have to be ready for the next sprint planning meeting. User stories likely to be implemented in the next sprint should now have well-formed acceptance criteria, for instance. Jointly grooming the product backlog ensures that it contains the right items in the right order. It also reduces the likelihood that an items implementation differs from how the product owner intended it to be realised. When it comes to product owner availability, I often suggest the one-hour rule: Product owners should spend at least one hour per day on average with their teams in the same room. This ensures that the product owner is available to answer questions and to provide feedback on work results.
Invest in quality: Product owners must understand that team members need time to create high-quality software and regard agile development practices like test-driven development and continuous integration as a great way to ensure sustained product health. Setting aside time for team members to experiment with new practices and tools may result a lower velocity in the short term, but it speeds up development in the mid to long-term.
Be clear on the difference between fidelity and quality. The product’s functionality evolves, and its fidelity may well increase during the project; the look and feel and the overall user experience might improve. But the software quality – as defined in the definition of done – should stay constant throughout.
Find out more about the product owner’s role in creating great products in my book Agile Product Management with Scrum, or attend one of my upcoming product owner classes.
RSS