Tag Archives: ready


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.

Product Canvas Creation Workshop Overview

The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience and the right features. This post explains how you can create your initial canvas using a collaborative workshop.

Note that many of the recommendations below also apply to other agile and lean product definition tools including a traditional product backlog.


The Product Canvas creation workshop wants to kick-start your solution validation and product definition activities. It helps you change the focus from problem validation – exploring if there is a need that the new product addresses – to building a product with the right features and the right user experience. The following picture summarises the workshop, and the rest of this post explains the details.


Everyone tasked with creating the product should attend the canvas creation workshop: the product owner, the team developing and testing the product, and the ScrumMaster or coach. This creates shared ownership, and it is likely to result in better decisions, as the entire team’s creativity and knowledge are leveraged.

I generally recommend that the stakeholders – the users, and customers as well as the internal stakeholders – do not attend the workshop, but share their ideas and feedback based on prototypes and product increments, for instance, in the sprint review meetings. This allows the product owner and the team to be creative before the stakeholders provide input.


Before you start the workshop, you should be able to confidently answer the following questions:

  1. Who are the product’s users and who are the customers?
  2. What problem does the product solve? What benefits does it generate for its users? What is the product’s value proposition?
  3. What business benefits does the product creates? Why should the company invest in it?
  4. What kind of product is it? What are the three to five features that make it stand out?

I like to capture the insights above using the Vision Board. But you can also employ other tools including Ash Maurya’s Lean Canvas and Alexander Osterwalder’s Business Model Canvas, as the following picture shows:

Being able to answer the questions above means that some problem validation has taken place prior to the workshop, for instance, by carrying out user observations and problem interviews. Note that the strength of the Product Canvas is solution validation – building the right product – and not discovering if the product should be built in the first place!

To ensure a smooth workshop, use a facilitator, for instance, the ScrumMaster. Organise an appropriate room with lots of wall space. Have the necessary materials available including paper sheets, paper cards, adhesive notes, masking tape, markers, and pencils. Starting out with paper and pencil is effective and fun in my experience, even if you intend to use a digital canvas.

Steps to Create the Canvas

To create your initial Product Canvas take the following three steps: Create personas; outline the user experience and the features; determine what to do in the first sprint, as the picture below shows:

The first step creates personas based on the insights gained in your problem validation work. The personas allow you to connect with the target users and customers. Their needs enable you to discover the right product features. I also recommend using a primary persona, as it creates focus and facilitates decision-making. You can read more about personas in the post  “A Template for Writing Great Personas”.

The second step describes the product comprehensively but at a rough, coarse-grained level. Helpful techniques to capture the user experience and the product functionality include scenarios, storyboards, epics, constraint stories, and design sketches / mock-ups. Make sure that the product features you identify address the need of a persona, or support the business model.

The third step determines what should be done in the first sprint. As you are about to start building the first product increment, you should address the greatest risk or the biggest uncertainty. This could be a lack of knowledge surrounding the user interaction, the user interface design, a product feature, or the architecture and technology. See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis. Finally, determine what needs to be done to reach the goal, or to test the hypothesis, for instance, creating a scenario and a paper prototype to learn more about the user interaction.

The three steps above form a breadth-first approach: The product is sketched holistically, but the details are determined on a sprint-by-sprint basis. This keeps your canvas concise, and allows you to make changes quickly and effectively.


At the end of the workshop you should have a Product Canvas that is good enough to start sprinting: to start building product increments/MVPs, gathering feedback, and integrating the insights gained, as the following picture shows:

Make sure you create a good-enough canvas, but not a perfect one. Your Product Canvas will change and evolve anyway based on the feedback you receive!


Four to eight hours should be enough time to create your initial canvas. If you require more time, then this may be a sign that you haven’t got enough information available and may have to carry out more problem validation and market research.


Employing a collaborative workshop, and following the process described above creates an initial Product Canvas that allows you to focus on solution validation – building the product with the right user experience and features. Make sure you understand the product’s value proposition before you enter the workshop, describe the product holistically at a coarse-grained level, and don’t worry too much about the product details: These will emerge incrementally based on the feedback you gather.

You can learn more about the Product Canvas creation workshop by attending my Certified Scrum Product Owner training course. If you would like me to help you run a Product Canvas workshop, then please contact me.

One of the things I love about user stories is their flexibility. A user story can be big, medium-sized, or small. This allows us to sketch a product with big stories, and then progressively add more detail and refine them into smaller user stories, as we learn more about how to meet the user needs.

But this flexibility comes at a price: I often see user stories that are too small or too big, that contain too much or not enough information. Deriving the right stories, and getting the level of detail right can be challenging.

This post suggests a simple, yet effective solution: distinguishing between two types of user stories, epics and ready stories, and deriving the ready stories with the help of a shared sprint goal or hypothesis.


Epics are big, coarse-grained user stories. An epic sketches a feature or bigger piece of functionality. It acts as a placeholder for more detailed stories. Think of the epos Odyssey. It’s a collection of stories about the adventures of Ulysses including meeting the Sirens, and defeating a Cyclops.

Epics allow you to sketch the product functionality without committing to the details. This is particularly helpful for new products or major product updates, as it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights: If you have lots of detailed stories, then it’s often tricky to relate the feedback you receive to the right stories, and it can be a big effort to change them without introducing inconsistencies. Let’s have a look at a sample epic:

The epic above tells us that the persona John wants to register for an event. The details of the event and the registration are left open for now. Similarly, the acceptance criteria – captured on the right card – are sketchy too. The details will emerge, as we learn more about the event registration by developing software and exposing it to the right people.

Ready Stories

Ready stories are small, detailed stories that can be implemented. These stories have to be clear, feasible, and testable: Everyone should have a shared understanding of the story’s meaning; the story should not too big or complex; and there has to be an effective way to determine if the functionality works as expected.

A ready story should also take into account additional aspects: the user interface design and the operational qualities that are specific to the story. Examples of the latter are performance or interoperability. I prefer to work with a paper-based design sketch to capture the user interface, and constraint story cards to describe the qualities, as the following picture shows.

The ready story above is much more specific and detailed than the sample epic discussed earlier: The details enable the development team to implement and test the story successfully.

From Epics to Ready Stories

So far we’ve simplified things by distinguishing between epics and ready stories. But we haven’t discussed yet how ready stories are derived from epics. My solution is to identify a sprint goal or hypothesis for the next iteration before the ready stories are written, as the following picture illustrates:

Step 1: Write the Epics

Let me show you how this process can be applied using my Product Canvas tool. The canvas is essentially a multi-dimensional backlog that allows you to describe your product holistically.

The Product Canvas supports working with epics and ready stories by providing dictated sections. It also offers the context for finding the right epics: The user journeys – scenarios, workflows, or storyboards – are a great hunting ground for epics. The epics are placed on the “Epics” section, as the following picture illustrates.

Step 2: Select the Goal of the Next Sprint

Once the epics sketching the product’s main functionality have been written, I populate the design and constraints sections on the canvas. Then I select the goal of the next sprint – either to address the most critical risk and/or to deliver functionality to the stakeholders including the users. Examples of a sprint goal are: “Validate our central user interface design ideas”, or “Be able to release epic B”. The sprint goal is placed at the top of the Ready Stories section, as the following picture shows.

I find it very beneficial to involve the entire team, the product owner and the development team, in selecting and formulating the sprint goal. This leverages the team’s collective knowledge, and ensures that the goal is shared. The latter ensures that the entire team is moving towards one goal. This encourages teamwork, and it makes it easier to analyse the feedback.

Step 3: Derive the Ready Stories

After selecting the sprint goal, I determine which epics contribute to the sprint goal, for instance, epic A and C on the canvas above. I then derive small stories from the appropriate epics, and I order the new stories depending on their importance to reach the sprint goal, as the picture below illustrates.

Finally, I ensure that each story is ready and has the necessary sketches and constraints attached. The entire teams should carry out this step to ensure that the stories are clear, feasible, and testable. The right amount of ready stories are then pulled into the sprint and implemented.

Step 4: Update the Canvas and Repeat the Process

After exposing the outcome of the iteration to the right people, the insights gained from analysing the feedback are worked into the canvas: Existing epics are adjusted or removed, new epics may be added. Then the next cycle starts. A new goal is selected, and new ready stories are written.


Working with epics helps you sketch the product’s functionality, and ready stories provide the input for the next cycle. This focuses your user story writing effort when developing a new product or new features. Employing a shared goal or hypothesis makes it easier to decide which ready stories should be written, facilitates teamwork, and makes it easier to analyse the feedback.

If you have any questions or feedback on working with epics and ready stories or on using the Product Canvas, then I’d love to hear from you! Post a comment, contact me on Twitter, or email me.

You can learn more about epics and ready stories by attending my Certified Scrum Product Owner training course or my Mastering the Product Backlog training course.

A Sample Canvas

The best way to understand the Product Canvas is to look at an example. Image that we want to develop a game that helps children enjoy music and dancing. A canvas for such a game could look like the one below.


The sample Product Canvas above contains the product name, the product (or release) goal and the metrics to measure if the goal has been met. The first bigger section states two personas characterising the target users and customers with their needs. The next section sketches important aspects of the product using epics to describe the product’s functionality, a mock-up to capture the user interface design, a storyboard to illustrate the user interaction, and a constraint card to express the platform for which the game is developed. The section on the right provides a goal for the next sprint and the details necessary to reach the goal.

The Sections Explained

As you have probably noticed, the Product Canvas combines form and function, a structure together with suggested techniques. The following diagram and the text below the sections of the canvas. You can download the canvas template for free from romanpichler.com/tools/product-canvas or by simply clicking on the picture below.


Name simply states the name or version of the product.

The Goal is the product or release goal, the objective that should be met, for instance, to acquire, activate or retain users. If you use the GO product roadmap than you can simply copy the relevant goal stated on the roadmap.

The Metrics provides the measure to determine if the goal has been met, for instance, number of downloads or daily active sessions. If you use the GO product roadmap than just copy the relevant roadmap metrics.

The Target Group describes the target customers and users as personas. The section explains who we believe is likely to use buy and use the product and why. I discuss personas in more detail in my post A Template for Writing Great Personas. Choose one primary persona – the persona you mainly create the product for. Employing a primary persona helps you make the right prioritisation decisions and create a product with a great user experience. Your primary persona should be at the top of the building block to signal its importance.

The Big Picture describes what is takes to meet the persona goals. It captures the user journeys, and the visual design required to create the desired user experience. As its name suggests, it wants to describe your product holistically at a high-level. The section is similar to the outline of a book: It captures the contents without discussing the details.

Scenarios, storyboards, workflow diagrams, and story maps are great techniques to describe the user journeys on the Big Picture. Each journey shows how a persona interacts with the product and the steps the individual has to take to meet a goal. The product functionality on the Big Picture is best captured as epics, which are big and coarse-grained user stories. Epics allow you to describe your ideas without having to commit to the details. This saves time, and it makes it easier to update the canvas with new insights. Constraint stories help you capture the nonfunctional requirements that impact the user experience and the software architecture. You can capture your visual design ideas on the Product Canvas as design sketches, mock-ups, screen-shots, and photos. The Big Picture design artefacts should focus on the critical design aspects of your product—for instance, the design of selected screens or pages.

None of these techniques are mandatory, of course. They rather provide you with a starting point. Choose those techniques that are appropriate for your product. Use additional ones as it suites your needs.

The Product Details provide a goal for the next iteration and just enough implementable items to reach the goal, for instance, to address a risk and to acquire relevant knowledge, or to complete a feature. Depending on the goal, I use different techniques to capture the implementable items. For goals that require coding, ready stories are very helpful. These are small, detailed stories that feed the next cycle and that help create a product increment or minimal viable product (MVP). They are derived from the epics, and are necessary to reach the sprint goal. Make sure you write acceptance criteria for your ready stories. Order the implementable items from one to n, for instance, first, second, third, and so on, to maximise the chances that you reach your goal.

Putting the Users First

The canvas is designed so that the information flows from left to right starting with the personas. This puts the user at the center of the development effort, and it ensures that you develop a product that is beneficial and desirable.

The scenarios, storyboards, epics, design sketches, and constraints describe the future product, and the ready stories ensure that there are implementable items. I explain in more detail how you can create you canvas in my post “The Product Canvas Creation Workshop“.

Learning and Emergence

The biggest challenge when developing a new product is to deal with uncertainty and lack of knowledge. We may not know, for instance, if there is enough demand for the product, or how users will interact with the product. The Product Canvas is designed as a learning tool: to sketch our initial ideas, to get enough stories ready for implementation, and to adapt and refine the content based on the insights gained. The following picture illustrates this cycle.

Consequently, you should expect that your canvas changes as you learn more about the users and customers, and how to best address their needs. It’s common to deal with bigger changes involving clearing out and refilling one or more canvas sections including the section on personas.

The Business Model

The Product Canvas describes the target group and the product features, but not the business model including the revenue sources and the cost structure. While I have intentionally kept the canvas focussed, I have designed it to be compatible with the Alexander Osterwalder’s and Yves Pigneur’s Business Model Canvas. You can use the two canvases together, as the following picture illustrates.

As the picture above suggests, I use the Business Model Canvas to capture the market and value proposition at a high-level, and I state the details for a specific product on the Product Canvas.


I like to work with a physical Product Canvas placed on the office wall, as this has three main benefits: First, it ensures that the relevant information is visible to the product owner and the team. Second, working with simple, yet effective tools such as paper cards and paper sheets facilitates effective collaboration. Third, having to work with limited wall space creates focus and prevents capturing everything that might be relevant. To create your own paper-based canvas, download and print out my free Product Canvas template.

If you require an electronic canvas, then consider using a wiki, or try Jolien Coenraets’ Google Drive template. There are also several software tools, which allow you to create a Product Canvas including the BMFiddle Product Canvas, the ProdPad, and the Canvas Model Design iPad app.

If you work with JIRA, I suggest you keep the personas and the big picture in your wiki or project management tool, and manage the product details in your JIRA board.


The Product Canvas brings together the key pieces of information necessary to create a new product: the users and customers with their needs, the product’s functionality and design, and the user interaction. It’s intended to be a collaborative tool that helps you state your ideas and assumptions, test them, and integrate the insights you gain. Try it out, and let me know how the canvas works for you! I’d love to learn how using the canvas has worked for you.

You can learn more about the Product Canvas by attending my Certified Scrum Product Owner or my UX and Scrum training course. Please contact me if you want me to teach the course onsite or if you are interested in a virtual training.

This post was last updated on 20th March 2014.

Please note that the product backlog board has been superseded by the Product Canvas, a new type of backlog designed for creating new products and for product updates aimed at new markets. It extends the backlog board and connects personas with the product features. Please see my post “The Product Canvas” for more information.

Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to many hundred items. Many backlogs don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of “features, functions, technologies, enhancements, and bug fixes,” as Schwaber and Beedle (2002) write. Such a list can work well for updating an existing product. But it is often insufficient for developing a new product.

Enter the Product Backlog Board

I have therefore started to work with a structured and hierarchical product backlog, which I have named “Product Backlog Board.” Here is a sample product backlog board:

The Product Backlog Board (click to enlarge)

The product backlog board depicted above provides the following elements:

  • A prioritised story area with a ready section and a section containing themes with their epics.
  • constraint area with the global operational qualities and the critical product design and user interface requirements.
  • An optional model area that contains requirement models.

I am not the first person to recognise that flat product backlogs can be inappropriate; Jeff Patton did so a few years ago when he developed his story maps, for instance. You could even use a story map within your product backlog board if you wanted.

The Story Area

The story area is divided into two sections: items that are likely to be worked on in the next sprint, and the other outstanding work that is essential to create a successful product. The items in the ready section must be clear, feasible and testable. They are preferably captured as small and detailed user stories with well-written acceptance criteria. The epics, however, are coarse-grained and sketchy. They are placeholders for future detailed stories which are progressively derived from them. Epics are grouped into themes with each theme representing a product capability.

The stories in the ready section must be strictly prioritised, from one to n, to focus the work of the team. You don’t have to order the themes and epics unless you want to indicate when functionality will be released, for instance, in form of an early product increment (beta). But don’t forget to review the epics on a regular basis, and consider risk and uncertainty as well as dependencies. This will help you to decide how to stock the ready section and to determine which stories have to be carved out of your epics.

The Constraint Area

This area contains the global non-functional requirements of the product – operational qualities as well as product design and user interface ideas that apply to the entire product. It’s important to recognise and address these constraints: They influence the user experience, drive architecture and the technology decisions, impact the total cost of ownership and the product’s life expectancy. I prefer to capture operational qualities using constraint cards. The critical aspects of product and user interface design are best described visually as sketches or screenshots of mock-ups and prototypes. Note that the items in the constraint area are not estimated. Instead, the definition of done states that all constraints must be fulfilled. (I discuss design in more detail in my post on Agile User Interface Design.)

The Model Area

Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by showing how the user roles interact with the epics. The same is true for workflows: It’s often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience. If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board. Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and workflows in more detail in my post on user story modelling.)

Making the Information Visible and Accessible

The product backlog should be visible and easily accessible for everyone involved in the development effort. I hence prefer to work with a physical product backlog board – paper cards and paper sheets put up on a large board or an office wall.

The Product Backlog Board on an Office Wall

On distributed projects the product backlog board can be easily stored as an electronic spreadsheet. Just remember to make it visible, for instance, by posting it on the project wiki.

Stocking the Product Backlog Board

I prefer to derive the contents of the product backlog board from the product vision board or the product roadmap and to focus its content on the items that are essential to develop the next product version or the next major public release. This reduces complexity, creates clarity, and avoids predicting an uncertain future.

When you stock the constraint area, resist the temptation to create the complete product and user interface design upfront. Rather focus on those aspects that significantly influence the success of the product and that are difficult to change at a later stage. The detailed design should evolve from sprint to sprint based on customer and user feedback.

“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:


“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.