Tag Archives: grooming

Simpsons

Story Mania

Some product owners and teams are so fond of user stories that everything is expressed as a story. This either results in some rather odd stories – stories that capture the user interface design, complex user interactions, and technical requirements; or these aspects are simply overlooked.

Like any technique, user story writing has its strengths and limitations. I find stories particularly well suited to capture product functionality, and when applied properly, nonfunctional requirements. But user interface design and complex user interactions are better described by other techniques including design sketches, mock-ups, scenarios, and storyboards. Complement your user stories therefore with other techniques, and don’t feel obliged to only use stories.


User Incognito

A user story tells a story about a user interacting with the product. Some stories, however, omit the beneficiary altogether, or they talk about a mysterious user as in “As the user, I want to …” But if it’s not clear who the user is, why should the story be developed? How can we be confident that the story will benefit someone?

Make sure that all your stories have a clear user or customer. As I like to work with personas, I use personas in my stories (instead of user roles). This connects each story to the right persona, and it allows me to understand if and to which extend the story addresses the persona’s need or goal. To achieve this, I use the following template: As <persona>, I want <something> so that <benefit>.


Disastrous Details

The devil is in the details: Some stories are too big and vague for the team to understand and implement. Others contain too much detail, or even prescribe a solution. Getting the details right seems to be a battle the product owner can only loose.

My recommendation is: Start with big, coarse-grained stories called epics particularly for all new features. Epics allow you to capture an idea without committing to the details. Then break an epic into more detailed user stories. The new user stories replace the epic, and they provide more information about the product’s functionality. Pay particular attention to the user stories that are pulled into a sprint. These stories have to be ready: clear, feasible, and testable. (You can learn more about decomposing epics into ready stories in my post “Epics and Ready Stories”.)

Progressively refining your stories keeps your Product Canvas or backlog concise, it makes it easier to integrate new insights, and it reduces the effort required to stock your initial canvas or backlog. This is particularly valuable for new products and new features. Make sure you do not prescribe a solution in your stories. Rather focus on the “what”, nor the “how”. The latter is best captured in an architecture diagram.


Story Handoff

Some product owners diligently write user stories, and give them to the development team in the sprint planning meeting. This handoff is usually suboptimal, as it wastes the team’s ideas and knowledge. Stories can hence be inappropriate, difficult to understand, unfeasible and not testable.

User stories, however, are not meant to be standalone documents. They should be complemented by a conversation between the product owner and the team, or even better: written collaboratively. A story wants to capture the essentials, and not specify every detail: The latter would be difficult for new features and too slow and too expensive in an agile / lean context.

User story writing should be a team effort, where product owner and development team create the stories together. Allocate time for a collaborative Product Canvas workshop or backlog grooming meeting, particularly when you develop a new product or new features. Trust me: Better stories and a better product will be your reward.


Criteria Crisis

Acceptance criteria are maybe the most misunderstood part of users stories. I have seen detailed stories with no acceptance criteria, criteria that restate the narrative, and criteria that hide new stories, or even contain entire workflows. The last two mistakes are exemplified by the following story (the narrative is on the card on the left, the “acceptance criteria” on the right):

The idea behind acceptance criteria is simple: They allow you to describe the conditions that have to be fulfilled so that the story is done, that it can be exposed to the users and the other stakeholders. This ensures that you gather feedback and/or release features, and it helps the team plan and track their work: The criteria enrich the story and make it more precise and testable. (The criteria all stories have to fulfil such as “online help is available” are not stated in the acceptance criteria but in the Definition of Done.)

As a rule of thumb, I like to work with three to five criteria per story, and I am not worried if my epics don’t have acceptance criteria to start with. Ready stories, however, must provide meaningful criteria. You can find sample acceptance criteria in my posts “Epics and Ready Stories” and “Nonfunctional Requirements“.


Learn More

“I don’t hate you for failing, I love you for trying,” says Marge to Homer Simpson. Making mistakes when writing users stories is part of the learning process. To learn more about writing user stories attend my Writing Great User Stories workshop. Please contact me if you have any questions or would like me to deliver the workshop onsite.

A well-groomed product backlog facilitates the development of a successful product: It incorporates the team’s learning, and provides items that are ready to be implemented. But when should grooming take place? Before the new development work starts or at a later point in time? And how can you decide which option is appropriate for your product? Continue reading to find out the answer.

Option 1: Grooming Takes Place before New Development Starts

Your first option is to groom the product backlog before any new development work starts, as the picture below illustrates. This includes obtaining feedback from users and customers, analysing it, integrating the learning into the backlog, and getting the product backlog ready. (Please see my post “The Product Backlog Grooming Steps” for a more detailed discussion of the grooming activities.)

Grooming takes place before more development occurs

Choose this option if you require feedback from customers and users to decide if and how to take your product forward. Let’s say you develop a new product and you are trying to understand if the solution addresses the user needs selected. It would then be advisable to collect the relevant data, for instance, by demoing the latest product increment or releasing it to the users, to analyse the data, and to integrate your insights into the backlog before you continue developing the software.

Employing this option may mean stopping coding for a few days before the relevant data is obtained and analysed. But this can be preferable over rushing on, only to find out later that the direction taken is wrong, and all the hard work has to be undone.

Option 2: Grooming Takes Place after New Development has Started

Your second option is to continue the development work while you are collecting and analysing the user feedback. The grooming is hence delayed, as the image below shows.

Grooming takes place after more development has started

Choose this option if you do not require the user data to continue developing your product. To put it differently, doing more coding without having first analysed the user feedback does not imply a significant risk of taking your product in the wrong direction.

There are two scenarios when delayed grooming may makes sense: Imagine you develop a new product and you are waiting for user feedback on the latest product increment. Now you want to validate a new, independent assumption, for instance, that you have selected a viable revenue source. So you decide to continue the development before you have analysed the feedback. Similarly, delaying the grooming work may be acceptable if you develop a mature product where swiftly reacting to user feedback is often not as critical.

Summary

Choosing the right point in time to groom your product backlog minimises the risk of developing the wrong product. It may be tempting to delay the grooming work, as it can be easier to write code than talking to target users and customers. But you should only employ this option if you do not require user input to decide how to take your product forward. Have the courage to stop and reflect on the feedback obtained rather than ploughing through your backlog items. To learn more about product backlog grooming, book a place on my Mastering the Product Backlog training course, or get in touch.

Grooming the product backlog means managing the backlog. This is necessary, as the product backlog changes and evolves: The team gains knowledge from exposing a product increment to the users, and the latest insights lead to a backlog update, as the picture below shows.

Much of the existing advice on product backlog grooming focuses on getting the backlog in shape to supply the development team with concise stories. Unfortunately, evaluating user feedback and integrating it into the backlog has been underemphasised. This blog posts tries to set the record straight by offering a holistic, five-step grooming process – from analysing user feedback to getting the backlog “ready”. Please note that I focus on new or innovative products rather than incremental updates of mature products.

Step 1: Analyse the Feedback

Grooming the product backlog starts with analysing the feedback collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on what’s feasible and beneficial. I prefer to work with both, qualitative and quantitative data.

When evaluating the feedback, focus on the data that is relevant to test your ideas and answering your questions. Have the courage to say no to new ideas and requests if these are not helpful to move you closer to your vision. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection, which usually results in a poor user experience.

Be aware of the cognitive bias we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. To mitigate the risk, analyse the feedback together with the team members. Remember that negative feedback is good feedback: If all you ever hear is positive, you are not learning anything new.

Step 2: Integrate the Learning

Once you have analysed the feedback, incorporate your insights into the product backlog. This results in removing, adjusting, and adding content: epics, operational constraints, design and workflow sketches. If the feedback invalidates you assumptions regarding the target group, the user needs, and the business model, you may have to adjust your vision board, remove the product backlog content, and restock your backlog.

Note that in the image above, the product backlog board’s top section is empty, as the high-priority items have been consumed, and new ready stories still have to be created. (This is done in step 4.)

Step 3: Decide what to do Next

After incorporating the learning into your backlog, decide what to do next. Ask yourself why you want to carry out the next cycle. What do you want to learn? Which ideas and assumptions do you want to validate? Which functionality do you want to provide? For new products or innovative features, your goal should be a testable hypothesis, for instance, by using the following format: If we do x, we will achieve y.

My goal for writing this blog post, for instance, is twofold: Consolidate my knowledge about the grooming process and understand if my recommendations resonate with my readers. The first sub goal is met by making time to write the post. The second one is attained if the post gets a comparatively high number of hits, generates a certain amount of Twitter traffic, and attracts meaningful comments.

Step 4: Create Small Stories

Next, carve stories out of the epics in order to reach your goal. Then make the stories high-priority, and order the stories according to their importance for reaching the goal, as the image below shows.

You may also want to ask the team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog.

Step 5: Get the Stories Ready

With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are “ready”: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the image below illustrates.

Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product. The stories should now be ready to be pulled onto the sprint backlog or the Kanban board.

Leverage Teamwork

When I talk to product owners about grooming their backlog, I often discover that the individual carries out the work largely alone. This wastes a massive opportunity: to mitigate the product owner’s cognitive bias, to create shared ownership of the backlog, and to leveraging the team’s collective wisdom and creativity.

As the product owner, involve the team members in the grooming steps. This reduces your workload, and it is likely to result in a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test your new ideas and assumptions.

Summary

When grooming your product backlog, don’t forget to collect and to analyse the user feedback. Integrate your insights, select your next goal, write small, detailed stories, and get them ready for implementation. Rely on your intuition as well as the data analysis, and involve the team in the grooming steps.

If you want to learn more about the product backlog, book a place on my Mastering the Product Backlog course in May in London or in September in Cambridge, or contact me.

The role of design still puzzles many Scrum and Kanban teams I work with. When should the design activities take place? Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by introducing my preferred design approach.

User-centric, iterative, and collaborative

The image above depicts the design process I employ. It’s user-centric, iterative, and collaborative. The process starts with capturing the design concept in form of a rough mock-up. Then the detailed design for one or more user stories is created and implemented as a throwaway prototype or as shippable software. The result is exposed to the users to understand if the design contributes to a great user experience. If it does, the design is refined, and the design for the next stories is created; if it does not, the design concept is reworked.

High-level Design

To get started, develop your design concept. The concept should sketch your key design ideas and communicate the essence of what you believe the product should look like. This includes the shapes and the colours you intend to use. Keep the overall product vision in mind together with the desired user experience: the kind of product being developed and the reason why people might want to use it. Focus on the critical aspects and don’t worry about the details right now.

For instance, the high-level design below shows how the structure, shapes and colours of our new homepage together with a photo of a bald guy with a beard and sticky notes.

High-level website design

Capture your design concept as a mock-up. Consider using a paper sketch similar to the one shown above. Paper sketches require less effort than wire-frames or other mock-ups; they are usually good enough to communicate the design idea. Make your sketch visible and put it on the product backlog board as shown below.

High-level design on the product backlog board

You may also want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model area. (You can find out more about the backlog board in my blog post “The Product Backlog Board“.)

Detailed Design

With your design concept in place, create the design for each user stories you want to implement. This is best done as part of the product backlog grooming work. Developing the detailed design should hence be a collaborative exercise that involves the developers and testers. This allows you to leverage the team’s collective creativity and to quickly discover which design options are difficult and expensive to implement.

Sketch the user story-specific design on a paper card and attach it to the story card, as the image below illustrates. The design depicts the details of one of the boxes on the homepage:

Detailed design for a story

Then implement the design either as a throwaway prototype or as shippable software, and expose the result to the users. Note that paper prototypes are often sufficient to test your initial design ideas. Resist the temptation to create a perfect design straight away: An unpolished implementation tends to generate more valuable user feedback than a super slick design.

Learning

Leveraging the user feedback to validate your design ideas does not mean that you don’t require a vision of what the product should look like. The opposite is true. You have to innovate for your users and cannot expect to be told what the product should look like.

Take the redesign of our website for example: Our customers, the organisations that pay for our training or consulting services, are important users of our website. Most of our customers are mid-sized to large enterprises. Having worked for large companies myself, I know that bigger organisations often prefer a more conservative look. But we wanted to create a website that that looks cool and that we like, not a boring corporate design. The challenge is hence to synthesise the wants and needs of the users and your own vision and ideas into a great design.

Synthesising needs and vision

Use the feedback to experiment and discover which design ideas don’t work and which do. Don’t be a slave to the feedback, but don’t cling to your ideas either. Analyse the feedback with an open mind and decide what to do: take it on board or discard it. Then either rework your design concept or adjust it, and create the detailed design for the next story.

Summary

Creating the design iteratively, taking advantage of the team’s collective creativity, and leveraging user feedback to validate design ideas maximises our chances of developing a product that with a great user experience, a product that users love. Happy designing and please let me know if my thoughts are helpful. I look forward to your comments!

Working with the product backlog can be challenging, and many product owners wrestle with overly long and detailed backlogs. The following ten tips help you use your product backlog effectively.

  1. Derive your product backlog from the Vision Board or the product roadmap. Your product backlog should describe one product.
  2. Make your product backlog DEEP. Ensure that is detailed appropriately, emergent, estimated, and prioritised.
  3. Use a multi-dimensional backlog like my Product Canvas for new products and for product updates aimed at new markets.
  4. Make your product backlog visible. Put your backlog up on the wall or if that’s not possible, on a wiki server where it can be accessed easily by everyone involved in the development effort.
  5. Keep your backlog focussed and concise. Your backlog is likely to change and grow based on customer and user feedback.
  6. Employ user stories to capture ideas and requirements. Start with epics and progressively decompose them into detailed stories thereby incorporating the user feedback.
  7. Use uncertainty and risk to decide how soon an item should be implemented. Addressing uncertain items early on allows you to test your ideas, to fail fast, and to learn how to continue.
  8. Capture generic operational qualities such as performance, robustness and interoperability as constraint stories; describe the product or user interface design visually, for instance, in form of sketches, mock-ups, and screen shots.
  9. Update your product backlog to incorporate the insights you have gained from demoing or releasing software to the customers and users. Involve the development team to leverage the team members’ knowledge and creativity. Include stakeholders as appropriate.
  10. Make sure the top items are “ready“: clear, feasible, and testable. This allows the team to turn the items into a product increment, and it facilitates a realistic commitment.

You can learn out more about the product backlog by attending my Certified Scrum Product Owner training course.

“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back”. Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for many years to find out. A few minutes will do.

Why Ready Matters

The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.

If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment. It is therefore important to ensure that there are enough ready items on the product backlog. Consequently, my Product Canvas uses a dedicated ready section, as the picture below shows:

What Ready Means

A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with ScrumA story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-prtiority ones facilitates clarity.

An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.

A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days by the way, as this allows the product owner to provide feedback on the software during the sprint.

Ready stories are the output of the product backlog grooming work. To put it differently, your grooming activities should result in ready stories.

What a Ready Story Looks Like

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and  what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are simply attached to the story, as the picture below illustrates:

Summary

“A Jedi must have the deepest commitment, the most serious mind,” continues Yoda in the Star Wars episode. Similarly, you should be committed as the product owner to creating high-priority product backlog items that are clear, feasible, and testable.

Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.