User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing user stories that help a team build great software can be challenging. The following list summarises five common user story mistakes to help you improve your stories.
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.
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 you 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>.
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.
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, not feasible and 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.
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“.
“I don’t hate you for failing, I love you for trying,” says Marge to Homer Simpson. We can all tell and write good user stories; we just have to practice it. And practice makes perfect, as they say.
If you want me to help you improve your user stories, attend one of my training courses or contact me. You may also find it helpful to check out my “10 Tips for Writing Good User Stories“.
Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals.
When we start developing a new product or new features, there are usually more unkowns than knowns, more things we don’t know than we know: We may not be clear on the user interaction, the user interface design, the product’s functionality, or the architecture and technology required to build the product. Our greatest challenge is therefore to deal with the uncertainty present, and the associated risks.
As a consequence, the early sprints should focus on creating the relevant knowledge, and addressing the key risks. Selecting a testable idea (hypothesis), and running an experiment are great ways to achieve the necessary learning. As testing ideas results not only in success but also in failure, you should expect to fail in the early sprints. Your Product Canvas or backlog, and your architecture are likely to see bigger changes driven by the newly gained insights.
As you acquire more knowledge, your focus should gradually shift from resolving uncertainty towards execution: building a product that is ready for general release. Rather than primarily testing ideas, you should now start completing features and incrementally adding new ones. Failure can still happen at this stage, but it is usually a sign that something has gone fundamentally wrong. Similarly, your Product Canvas or backlog should have started to stabilise and exhibit less volatility. The change of focus may also impact your Definition of Done: Throwaway prototypes used to test ideas quickly don’t have to have the same quality as software that will be shipped. You can now start ramping up the project, add new teams, and consider employing distributed teams.
The following picture visualises the relationship between learning and execution for the development of a new product or a new product version:
To understand how much learning and experimentation is required, consider the amount of innovation present and the technologies used: A brand-new product usually requires more experimentation than a product update; and a web app developed with standard technologies is faster and easier to create than an embedded system or a mainframe application (assuming that some market research or problem validation has already taken place).
Understanding the relationship between learning and execution has three main benefits:
First, it allows you to set and manage stakeholder expectations. It helpful for the stakeholders to understand that the early product increments are likely to be throwaway prototypes, and that failure is to be expected in the first few sprints.
Second, it helps you choose the right sprint goals, and focus the work of the development team: Your early sprints should acquire the relevant knowledge by carrying out experiments. You later sprints should build features and get the software ready for general release.
Third, it makes it easier to select the right research and validation techniques. You may want to work with user tests and product demos in your early sprints, and with releasing software to selected users in the later ones.
Innovation – creating a new product or new features – involves uncertainty and risk. To build the right product with the right features quickly, you should make a concentrated effort in your first few sprints to quickly address the key risks and acquire the relevant knowledge. Then shift your focus to completing features and adding new ones by creating software that can be released.
You can find out more about learning and execution in Scrum by attending my Certified Scrum Product Owner training course.
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:
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.
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.
User stories are great at capturing product functionality. But they are less suited to describe the user interaction in more detail. This is where scenarios and storyboards come into play: Both are great tools to describe the interaction steps. In this post, I explain what scenarios and storyboards are, and how they can be used effectively in an agile context, and how the two techniques relate to user stories.
Scenarios and storyboards are great to explore and describe how a user interacts with a product. When we started to work on the re-launch of our website, for instance, I wrote the following scenario:
The scenario above describes the steps Mary has to take to book a seat on one of our public training courses. Mary is a persona who represents a user of our website: an HR employee of a large company, and who’s main need it is to book employees on a training course.
Note that I have tried to make the scenario descriptive and engaging while focussing on the key aspects of the interaction.
Storyboards are similar to scenarios: They illustrate the interaction required to achieve a goal. But instead of using a list of steps, a storyboard visualises the interaction similar to a comic strip. Here is a sample board I created to explore another interaction for our new website:
The storyboard above describes how the persona Mary books several employees on the same training course. The board consists of a series of frames. Each frame shows sample data. Underneath it, I added a brief description of what Mary does at each step.
Note that I have done my best to describe the functional aspects of the interaction, and not to design the user interface: When I was working on the board, we did not have any design sketches and mock-ups available. I generally find it good practice to capture the product functionality necessary to meet the main user needs before designing the user interface.
User stories are another technique to describe the user interaction. A large story or epic allows us to summarise the interaction acting as placeholders for more detailed stories. I like to think of an epic is as a scenario rolled up into a brief narrative: it hides all the specifics of the user interaction. Detailed stories correspond to individual steps in a scenario, and describe a specific piece of product functionality.
The first thing I usually do when working on a new product is to write epics. To discover the right ones, I use the needs of the personas. Starting out with epics helps me quickly sketch the new product functionality, and it keeps the Product Canvas or product backlog concise and manageable.
But working exclusively with epics can be problematic, particularly when the epic carries risk: If we only have a coarse-grained description available, then it’s difficult to test our assumptions about how the users interact with the product. I therefore prefer to create a scenario or storyboard for risky epics, as the picture below shows:
Creating scenarios or storyboards for selected epics allows me to explore the user interaction in more detail, to describe the necessary steps and their relationship. This helps me test my assumptions, for instance, by creating a paper prototype that implements the scenario in order to carry out an early user test.
This is, of course, not the only way to combine scenarios and user stories. You can also derive stories from a scenario, and you can use a scenario to illustrate the relationship between different stories. The following diagram illustrates the three options:
Choose the options that are most helpful in your context, and combine them, as it makes sense. You can, for instance, start with the first option (as I did above), then derive new stories from your scenario or storyboard, and finally capture the relationship between the new stories in a new scenario.
Scenarios and storyboards are great tools to describe how users interact with a product. They also complement user stories nicely: Scenarios and boards help explore risky stories, discover new user stories, and capture the relationship between stories. Make sure you include scenarios and storyboards in your product owner toolbox.
You can learn more about working with scenarios and storyboards by attending my Certified Scrum Product Owner training course.
Product planning is just as important in an agile context as it is in a traditional setting. Unfortunately, some product owners focus so much on the product details and the tactical level that other planning aspects are neglected. But writing the right user stories and creating the right user interface design is difficult, if we haven’t thought about the product strategy; and choosing the right strategy is hard if we don’t have a vision of what we want to achieve.
Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates:
The level of detail increases, as we move down from the vision to the tactics: Whereas the vision is typically captured by a brief statement, the strategy communicates different aspects including the market or market segment targeted, the product price and the channels, and the product’s unique selling points (USP’s). The tactics go further by describing the product details employing, for instance, user stories, design sketches, scenarios, and storyboards, as the following picture shows:
Product planning starts with creating a vision: an overarching, shared goal that guides people. A sample vision from my own company is: “Grow Pichler Consulting without increasing headcount.” This vision may not sound mega exciting but it is very helpful for my team and me: It guides our work and focuses our efforts. Note that the sample vision doesn’t mention a specific product or service. It rather states a business goal. How the goal is realised is captured in the product strategy.
The product strategy is the path chosen to realise the vision. Without a strategy, making the right decisions about the product details is difficult: the functionality, the design, and the non-functional properties the product should exhibit. Having a strategy in place also prevents me from getting lost in the details.
I find it helpful to capture the target group, the needs addressed, the key features of the product, and the desired business benefits in the product strategy. But you may want to add the product price, the channels, the main competitors, and other important business model elements to characterise your strategy more comprehensively.
As the strategy is a path to the vision, it may turn out to be wrong. This is particularly likely when a new product is created. Changing the strategy is also called a pivot. My strategy for growing Pichler Consulting, for instance, is to develop an e-learning course. If I discover that the course is unlikely to be successful, I may change the strategy and write a new book instead. While the strategy may turn out to be wrong, the vision should still be valid.
The product tactics describe the product details: the product functionality, the user interaction, and the user interface design. Great techniques to capture these aspects are epics and ready stories, scenarios, design sketches and mock-ups, constraint stories, and sprint goals. New product features are best delivered incrementally so we can learn from the feedback we collect. I use blog posts, for instance, to create the material for my e-learning course. This allows me to learn from the feedback I receive, and to validate my strategy and the product details.
I prefer to use the agile product planning tools shown in the picture below:
For new or innovative products, I employ the Product Vision Board and the Business Model Canvas. The former helps me capture my vision and the key elements of the product strategy; the latter helps me describe additional aspects including price and channels. To capture the details, I use the Product Canvas. The canvas allows me to work with personas, epics, scenarios and storyboards, design sketches and mock-ups, constraint stories, sprint goals, and ready stories.
For incremental product updates, I like to employ a goal-oriented or theme-based product roadmap in order to capture the product strategy. I normally use a traditional product backlog to describe the product details.
Creating successful products requires more than attention to the product details. Ensure you have a shared in vision in place, and choose a strategy that guides you towards the vision. Use early feedback to validate if you are on the right path, if your strategy is valid. Let the product strategy help you decide what your product should look like and do.
You can learn more about agile product planning and creating a powerful vision and product strategy by attending my Agile Product Management training course.
I don’t know about you, but every time I read the word “nonfunctional”, I feel a yawn coming on, and I start to look for something else to do. While nonfunctional requirements or quality attributes, as they are also called, may not be sexy, they are still important: They impact the user experience, and they influence architecture and design decisions.
Say you are looking for a new car, and you’ve found one that looks great. The car also has a powerful engine, lots of safety features, and a sat nav. But during a test drive, you discover that it’s noisy inside the cabin, the seats aren’t comfy, and the actual fuel consumption is surprisingly high. While the car has all the right features, the driving experience is not great – and that’s due to its poor nonfunctional properties.
Another example is the training part of my website. If its performance is poor, and if it takes too long to receive a confirmation once a participant has been registered, users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard.
As important as they are, nonfunctional properties are sometimes overlooked, particularly in an agile context where we spend less time with upfront research and analysis. This can be particularly painful for those attributes that apply to the entire product. If, for instance, you forget to capture that your mobile app should be available on iOS and on Android, then this may require correcting fundamental architecture and technology choices, which is likely to delay the project or make it more expensive.
If you are unsure which nonfunctional requirements are important for your product, then I suggest you engage with the users and the development team. Try observing users, conducting problem interviews, and carrying out user tests using early product increments / prototypes. The tests allow you to discover new attributes and to understand if, for instance, the performance is acceptable.
The development team is a great partner for finding relevant nonfunctional requirements, particularly if the team members have worked on a similar product before or deal with support and production issues. If that’s not the case, then you should consider inviting members of the operations and customer services group to listen to their views on qualities such as robustness and availability.
I like to capture nonfunctional requirements as constraint stories. Here is an example:
I call the story above a constraint, as it constraints other user stories. But just like a regular story, the constraint has two parts: a narrative and a list of acceptance criteria. The narrative describes the nonfunctional requirement from the perspective of the persona Mary. The criteria clarify the interaction and describe the environment. Both are required to validate the constraint. (Tom Gilb’s Planguage, which is an alternative approach to describing nonfunctional requirements, would call the first condition “scale” by the way. The narrative contains the “target” and the “gist”.)
Whatever format you choose to capture your nonfunctionals, ensure that the description precise and testable. If I say, for instance, that booking a training course on our website should be quick, then that’s a first step towards describing the attribute. But it would be too vague to characterise the desired user experience, to help the development team make the right architecture choices, and to validate the constraint. I will hence have to iterate over it, which is best done together with the development team.
Explore nonfunctional requirements that apply to the entire product or to important features early on. This helps you create a great user experience, and make the right architecture and technology decisions. Capture the requirements precisely to ensure testability. And don’t rush to test-drive a Ford Shelby Mustang GT500 depicted at the top of this post. It’s not the greatest sports car on the planet – at least according to Top Gear’s Jeremy Clarkson.
You can find out more about working with nonfunctional requirements by attending my Certified Scrum Product Owner training course. Unfortunately, I won’t be able to tell you more about Mustang cars: I’ve only driven one many years ago and only for a few miles. All I remember is: It was fast.
The product backlog is an important tool: It lists ideas, requirements, and new insights. But is it always the right tool to use? This post discusses the strengths of a traditional product backlog together with its limitations. It provides advice on when to use the backlog, and when other tools may be better suited.
The GoodA traditional product backlog lists the outstanding work necessary to create a product. This includes ideas and requirements, architectural refactoring work, and defects. I find its greatest strength its simplicity, which makes it incredibly flexible to use: Teams can work with the product backlog in the way that’s best for their product. Items can be described as user stories or as use cases, for instance, and different prioritisation techniques can be applied. This flexibility makes it possible to use the backlog for a wide range of products, from mobile apps to mainframe systems.
The second great benefit is the backlog’s ability to support sprint and release planning. This is achieved by ordering its items from top to bottom, and by detailing the items according to their priority. Small, detailed, and prioritised items at the top are the right input for the sprint planning meeting. Having the rest of the backlog ordered makes it possible to anticipate when the items are likely to be delivered (in combination with a release burndown chart).
The BadWhile simplicity is its greatest strengths, I also find it a weakness: Personas to capture the users and customers with their needs don’t fit into a list, nor do scenarios and storyboards. The same is true for the user interface design, and operational qualities such performance or interoperability.
As a consequence, these artefacts are kept separately, for instance, on a wiki or in a project management tool, or they are overlooked in my experience. While the latter can be very problematic, the former isn’t great either: information that belongs together is stored separately. This makes it more difficult to keep the various artefacts in synch, and it can cause inconsistencies and errors.
Similarly, working with a product backlog that consists of a list makes sense when release planning is feasible and desirable. For brand-new products and major product updates, however, the backlog items have to emerge: Some will be missing initially and are discovered through stakeholder feedback, others are too sketchy or are likely to change significantly. To make things worse, a team working on a new product may not be able to estimate all product backlog items at the outset, as the team members may have to find out how to best implement the software.
The UglyI have seen quite a few ugly product backlogs in my work including disguised requirements specifications with too much detail, long wish lists containing many hundred items, and “dessert backlogs” consisting only of a handful of loosely related stories. While that’s not the fault of the product backlog, I believe that its simplicity does not always give teams the support they need, particularly when a new product is developed.
A traditional, linear product backlog works best when the personas, the user interaction, the user interface design, and the operational qualities are known, and don’t not have to be stated. This is usually the case for incremental product updates. For new products and major updates, however, I find that a traditional product backlog can be limiting, and I prefer to use my Product Canvas. (But the canvas would most likely be an overkill for an incremental product update or a maintenance release!)
No single tool fits all needs and excels in all scenarios. Choose your tool to capture ideas and requirements wisely, and use the degree of innovation present in you product to select the right one. You can learn more about the product backlog and my Product Canvas by attending my Certified Scrum Product Owner training course.
This post helps you use your product demos as an effective agile market research tool: to collect relevant feedback in order to validate your ideas and improve your product. If you employ your demos to sign off user stories then this article will show you how to get much more out of them.
In an agile approache like Scrum, the latest product increment is demoed to the stakeholders in the sprint review meeting, as the picture below illustrates. (Please see my post “The Scrum Cycle” for a detailed explanation of the picture.)
While the product demo allows understanding which stories have been completed, I find that using it as qualitative market research technique unleashes its real potential. Its primary goal is then to collect feedback from users and other stakeholders in order to validate ideas and improve the product. The demo is best done in person with everyone being present in the same room, but you can also conduct it as a videoconference. The following tips should help you leverage your product demo as an effective market research method.
Understand what questions you would like to get answers to, and what ideas you would like to validate before conducting the demo. Your sprint goal should help you with this: If, for instance, your sprint goal is to test your user interface design ideas, then you should plan the demo accordingly: You may want to present different versions as mock-ups to the users to understand which one they prefer and why that’s the case. Having one sprint and research goal helps you focus the presentation. It increases the likelihood to collect relevant feedback, and it makes it easier to analyse the feedback.
Use your sprint goal to decide who can help you validate your ideas and improve the product and who should therefore attend the demo. If the goal of the sprint is to establish the right software architecture decisions, then end users are probably not the right attendees. In the worst case, the demo could be a frustrating experience and prevent them from attending another review meeting. But if the goal is to better understand how users are likely to interact with the product, then end users should be present. Otherwise, you are in danger of collecting lots of interesting but irrelevant or misleading data.
Avoid listing features and functionality in your demo, and describe what the product does for the user in order to receive meaningful feedback. A great way to do this is to use a scenario. If you develop a mobile banking application, for instance, you may want to say: “Imagine you are on the train on your way to work, and you remember you still need to pay your water bill. You open the banking app, log on, and then you would see the screen I am showing you now.” If you employ my Product Canvas, then you should be able to use its scenarios and storyboards for your demos.
An agile product demo should not be a one-way communication or a sales event. Instead, its objective is to generate valuable feedback that allows you to gain new insights. Unfortunately, users and other stakeholders don’t always provide helpful feedback straight away. You sometimes have to ask the right questions and create a dialogue. For instance, if the feedback you receive is “Great demo, I really like the product”, then that’s nice. But what does it actually mean? How does it help you, and what can you learn from it? Dig deeper, ask why the individual likes the product, which aspects are particularly valuable, and which could be improved.
To be able to analyse the feedback afterwards, I recommend you record who provides the feedback and what you hear and see. Ask the team members to take notes too. This reduces the risk of overlooking feedback. I also suggest you record relevant background information about the attendees including demographics and job role. The information will be handy when you analyse the feedback.
I prefer to separate collecting the feedback from analysing it. This allows me to listen to the users, and to decide afterwards what I can learn from the information gathered by carefully considering if the feedback is relevant and how it is best acted upon. It also makes it possible to compare notes with the team members thereby leveraging the collective wisdom of the team and mitigating cognitive biases. But I do suggest that you reject an idea or request immediately if you know that it does not make sense or that it is impossible to take it on.
A product demo is a great tool for getting feedback particularly in the early sprints when the product has not enough functionality to be exposed in other ways to the users. But it does have a drawback: Users provide feedback based on what they see and hear. The demo does not validate how people actually use the product. I hence recommend you employ user tests and software releases once your product has progressed further. This allows you to understand better how the users interact with your product, and how well your product meets their needs.
A product demo is a great tool for collecting feedback particularly in the early sprints. To fully leverage your demos, make sure that you understand your research goal, invite the right people, explain what the product does for the user, create a dialogue, record the feedback, do the analysis afterwards, and consider employing user tests and releases as soon as your product as progressed further.
You can learn more about product demos in Scrum by attending my Certified Scrum Product Owner training course and my Agile Product Management training course.
Having used the Product Canvas in my client-facing work and on my own projects, and after starting to teach Product Canvas tutorials, I have put together the slide deck below to help you create your own canvas.
The slides explain what the Product Canvas is, and how it can be used effectively. The deck shows how to create an initial canvas using personas, epics, scenarios storyboards, design sketches, constraint stories, and ready stories. It covers how the canvas is updated to incorporate the insights gained from analysing user feedback, and it discusses different tool options.
Please let me know if you have any questions or feedback on the slides. I’d love to hear how you the product canvas works for you! Please contact me or add a comment below.
Owning a product sounds great. But what does it mean? How can we test if an individual or team owns a product?
An individual or team truly owns a product if the person or group has the right to say no. Don’t get me wrong. I don’t want to promote a negative mind-set or can’t-do attitude. But as Steve Jobs said: “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.” If we take on every idea or feature request, we are likely to end up with a bloated product that is expensive to develop and that provides a poor user experience.
In a cyclic process such as Scrum, feedback from stakeholders is regularly used to understand if the right product is developed, as the following picture shows:
In the picture above, the team creates a product increment guided by the overarching vision. Feedback is then obtained by exposing the increment to the right people. These include users and customers as well as internal stakeholders such as representatives from marketing and sales. Demoing or releasing the increment results in new ideas or requirements. Sometimes powerful stakeholders such as a management sponsor or customer request new features based on what they have seen.
Any constructive feedback is good feedback and should be welcome, but not all feedback is helpful and relevant. It’s the job of the people creating the product to analyse the feedback and to decide which pieces are and which aren’t relevant. Feedback is irrelevant when the data quality is poor, for instance, if a piece of information is unclear or ambiguous, or if the feedback is not helpful to reach the vision or release goal.
The relevant feedback is used to change the product backlog or product canvas thereby shaping the next product increment and progressing the product further. But any irrelevant data should be disregarded, symbolised by putting it in the trashcan in the picture above.
Disregarding feedback implies the right to say no. It may mean telling a customer that a feature request will not be fulfilled, at least not in the near future. Being empowered to push back, to filter and select, puts the people creating the product in control. It allows them to move fast, to try out new ideas, and to decide what the product should look like and do. But it also implies being responsible for making the product a success: developing a product that does a great job for its users and the company.
To find out if you truly own your product, ask yourself: Am I empowered to disregard feedback and reject requests? Can I say no, even to powerful stakeholders? Exercising agile product ownership requires a positive answer to both questions.
You can learn more about product ownership and the product owner role by attending my Certified Scrum Product Owner training course.
Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why they matter, how to write and to track them.
A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature”, or “Provide the missing reporting functionality”.
Every sprint should have one shared goal. This ensures that everyone moves in the same direction. Once the goal has been selected, the team implements it. Stakeholder feedback is then used to understand if the goal has been met, as the following picture shows.
I have found that working with a sprint goal has five main benefits, particularly for new products and new features: It facilitates prioritisation and effective teamwork; it makes it easier to obtain and analyse feedback; and it helps with stakeholder communication.
A shared sprint goal facilitates prioritisation: It makes it easier to determine which stories should be worked on in the next cycle. Here is how I do it: I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal.
Sprint goals create focus, facilitate teamwork, and provide the basis an effective sprint planning session. A shared objective guides the development work, encourages creativity, and enables commitment. Teams don’t commit to individual stories in Scrum; they commit to the sprint goal.
Employing a sprint goal makes it easier to collect the right feedback. If the goal is to evaluate the user experience, for instance, then it is desirable to collect feedback from actual target users. User representatives should therefore attend the sprint review meeting. But if the goal is to reduce technical risk by evaluating different object-relational mapping tools, then it is probably more appropriate to invite an experienced developer or architect from another team to discuss the solution.
Working with a sprint goal helps analyse the feedback obtained. If the team works on several unrelated stories in the same sprint then it can be tricky to relate the feedback to the right user story. This makes it harder to understand if the right product with the right features is being built.
Finally, imagine meeting the big boss in the elevator and being asked what you are working on. Chances are that without a sprint goal, the boss will be bored to death, jump onto a specific story, or he will have left the elevator before you are finished listing all the things you do. Using a sprint goal helps you communicate the objective of the sprint to the stakeholders. This allows them to understand what the sprint is about and to decide if they should attend the next sprint review meeting.
Like any operational goal, a sprint goal should be SMART: specific, measurable, attainable, relevant, and time-bound. As sprints are time-boxed iterations, every sprint goal is naturally time-bound: It has to be reached by the end of the sprint.
A relevant sprint goal helps you address the most important challenge, and it moves you closer towards your vision or release goal. For a new product or a bigger product update, the main challenge in the early sprints is to resolve uncertainty and to mitigate the key risks. To determine where the greatest risk currently is, I use the three innovation drivers – desirability, feasibility, or viability – as the following picture shows.
A sample goal of an early sprint is to learn more about the desired user experience (a desirability aspect), the software architecture (feasibility), or the pricing model (viability). To pick the right goal, choose the risk that is likely to hurt you most if it is not addressed immediately.
When selecting your sprint goal, remember that trying out new things requires failure. Failure creates the empirical data required to make informed assumptions about what should and can be done next. Failing early helps you succeed in the long term.
After you have run a few sprints, the emphasis usually starts to shift from resolving uncertainty to completing features so that they can be released – at least to selected users. This allows you to gather quantitative data and to understand how users employ your product in its target environment. The shift should be reflected in your sprint goal, which now focuses on “getting stuff done” rather than testing ideas, as the picture below illustrates. (I explain this development in more detail in my post “Get Your Focus Right“.)
Employing a specific and measurable sprint goal allows you to determine success. For instance, don’t just state “Create a prototype” as your sprint goal. Be explicit about the type and its purpose. Say instead: “Create a paper prototype of the user registration feature to test our user interaction ideas.”
The default mechanism in Scrum to determine success is to analyse the stakeholder feedback. Scrum suggests that the feedback should be obtained in the sprint review meeting by presenting the product increment. If this is not appropriate for you, then I suggest you make your approach explicit in your sprint goal. Write, for instance: “Test the user interaction design of the registration feature by conducting a user test in the sprint review meeting.”
Carrying out sprint planning activities ensures that the sprint goal is attainable. Traditionally, this involves selecting user stories that are required to reach the goal until the team’s capacity has been consumed. Sprint planning hence allows the product owner and the team to understand if the goal chosen can be reached. This helps you to invite the right stakeholders and be confident that they can provide meaningful feedback. Unrealistic sprint goals waste the stakeholders’ time and undermine their willingness to participate in the process.
To ensure that the sprint goal is fully leveraged, I visualise it. My product canvas tool contains a ready section with items for the next sprint, as the picture below shows. I place the sprint goal at the top of the ready section, and I determine the stories required to reach the goal. These are then listed underneath the goal.
As part of creating the task board or sprint backlog, I move the sprint goal from the product canvas onto the board. This helps ensure that the team keeps the goal in mind when implementing the individual stories.
“You’ve got to be very careful if you don’t know where you are going, because you might not get there,” says Yogi Berra. Employing a sprint goal increases that chances of getting where you want to go, of creating a successful product.
You can find out more about employing sprint goals effectively by attending my Certified Scrum Product Owner training course.
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 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.
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:
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.
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.
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.
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.
”This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit-hole goes,” says Morpheus to Neo in the movie “The Matrix”. This quote reminds me of the choice we face when dealing with a new product idea: Should we walk away from it, or should we jump into it? And how can we tell?
To help product owners and teams decide if and how to progress an idea, I have developed a tool called the Product Vision Board. The board captures important assumptions that influence the product success, and it allows teams to start testing and refining their ideas. In this post, I explain how the vision board can be applied to kick-start the innovation process and to create a new software product.
I’ve recently had the idea of developing an electronic tool, a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to properly capture the user experience including the user interaction and the user interface design. Since I published the canvas in July 2012, I have received lots of encouraging feedback. Some of it suggested an electronic version, and Johan Steenkamp started to work on a free, web-based product canvas as part of his BMFiddle.
After loosely collaborating with Johan for a couple of months, I was wondering if an enhanced digital canvas would be a good idea. It was like weighing up which pill to take: Take the blue one and leave the tool development to Johan, or take the red one and commit time, money, and energy? To help me make the right choice, I created a vision board for a new electronic product canvas. But before I introduce the board to you, let me briefly remind you what the vision board is all about.
The product vision board captures the initial ideas and assumptions for a new product, as the following picture illustrates.
The board above describes the overarching vision that guides the product. It states who should use and purchase the product (Target Group), why people would want to use and buy it (Needs), what the key product features are (Product), and why the organisation should invest money in the product (Value).
It’s important to understand that the vision board is intended to initiate the innovation process. It does not want to describe the users, the product, and the business model comprehensively or in great detail. It rather captures the critical assumptions, those assumptions that will make or break the product. More information is provided later in form of the Product Canvas and the Business Model Canvas, as the following picture illustrates.
To clarify my thoughts, I sat down and created a new product vision board. While I am a great fan of simple, physical tools, I decided to create an electronic vision board, as I wanted to share the board with Johan who lives in New Zealand, whereas I am based in the UK. Here is what I came up with:
To create the board, I started with the vision statement keeping it intentionally broad. This allows me to follow the vision even if my electronic tool idea turns out to be ill conceived. At the same time, the vision reminds me that the new product is only means to an end: to help organisations create great products.
Next I recorded my ideas about the users. In addition to product managers and product owners, individuals setting up their own business might find the tool helpful. As I am particularly unsure about this group, I have marked it in italic. I use this convention on the other sections of the board, too.
I then focussed on the user needs formulating them as goals, for instance, being able to share the canvas with remote team members. Note that I have ranked the needs according to my current knowledge. Additionally, I have introduced a barrier: I believe that concerns about intellectual property and data theft may prevent people from using an electronic canvas. If the assumption is correct then it’s likely to have an impact on the solution and on how it is marketed.
In the next step, I listed those product features, which I consider to be particularly important to create value for the users. I was careful not state a specific solution such as an iPad app, or a web app. This would be premature at this point in time and narrow down the options too quickly. Before I decide on the product specifics, I want to validate the needs of the target group first. As a consequence, the vision board may change based on the new insights.
Finally, I stated the motivation for my business to invest in an electronic canvas tool. Similarly to the other sections, I have tried to focus on what I believe are the key assumptions and not be tempted to design the business model before I haven’t learned more about the users and their needs. After all, the business model will only work if the needs are met well!
I also found it helpful to state what I view as an investment barrier: If the electronic canvas tool incurs high running cost then this is likely to prevent me from funding the product development effort.
The next step for me is to validate my assumptions starting with the most critical one: the target group and the needs. I am planning to conduct a series of problem interviews focussed on the issues product owners and managers experience today when they identify, capture and modify requirements, as the picture below shows.
Problem interviews focus on the user needs, their goals and pain points rather than the product itself. In fact, it’s a good idea to exclude any product validation form the problem interviews, and not to ask, for instance: “Would this feature be helpful?” There are other research techniques, of course, for instance, observing users, but I am confident that interviews are adequate for now.
The interviews will hopefully help me validate my assumptions and allow me to learn more about the users. This should enable me to narrow down the solution and decide, for instance, to develop an iPad application, as well as help me find a viable business model. As Morpheus puts it: “Welcome to the desert of the real.” For as long as we just assume and hypothesise, we live in a dream world. By testing our ideas, we face reality.
If you would like to share your experience working with product boards, canvases, or backlogs, if you have any thoughts about what an electronic tool should do for you to capture, test and refine your product ideas, or if you have any specific questions about the Product Vision Board or the Product Canvas, then I’d love to hear from you. Please drop me a line either by email or via Twitter.
You can learn more about applying the product vision board by attending my Agile Product Management training course.
We all know the world is not flat, and Scrum is not a linear process. But some Scrum teams use feedback only to improve the process, and forget to apply it to the product. User stories are consequently turned into software without learning from stakeholder feedback and adapting the backlog. This wastes a massive opportunity: to ensure that the right product with the right features is created. In this post, I discuss how Scrum’s cyclic nature helps you create a great product by running focused experiments.
A linear Scrum implementation transforms the highest-priority product backlog items into a product increment without feeding back the insights gained from exposing the software to the right people – users, customers, and internal stakeholders.
Such an approach assumes that the Scrum team already knows who the product is for, and what the product should look like and do. This may be appropriate for small incremental product updates with virtually no market and product-related uncertainty present. But it is insufficient for new products and bigger updates, where discovering how the user needs can be best met is a major challenge.
Scrum’s cyclic nature enables experimentation and learning: The product evolves based on the feedback of users, customers, and other stakeholders. Applied correctly, this results in a desirable product: a product that does a great job for its users. The risk of building something that nobody really wants is minimised. The following picture describes four key steps that help you iterate towards a great product.
In the first step of the cycle, product owner and team select a sprint goal that describes why the sprint should be run. At the early stages of a development effort, the sprint goal should focus on testing assumptions and acquiring the relevant knowledge.
Make sure you ask the right leap of faith questions and tackle the right area of uncertainty. Understanding your innovation drivers will help you do this. Once the sprint goal has been selected, the team develops the appropriate product increment.
In the second step, the product increment is exposed to the stakeholders. To do this, Scrum uses a product demo as part of the sprint review meeting. Alternatively, you can ask the users to test the product increment in the review meeting, or you can release the software and collect the relevant data.
In the third step, the Scrum team analyses the feedback and the data obtained. This includes reviewing the quality of the data, and assessing its relevance. Examining the data should help the team understand if a desirable product is being developed. But it does not mean saying yes to every idea or stakeholder request! Similarly, negative feedback should be welcomed. If all you get is positive responses, then you are likely to ask the wrong questions or the wrong people.
I am a big fan of involving the entire Scrum team in this step, product owner, development team, and ScrumMaster. This leverages the team’s collective knowledge, encourages shared ownership, and it mitigates cognitive biases – the risk of overlooking or misinterpreting data.
Finally, the Scrum team uses the newly gained insights to adapt the product canvas or backlog. This may result in big, radical or small, incremental changes depending on the sprint goal and the feedback received. If, for instance, the feedback invalidates the user experience approach chosen, bigger changes are probably necessary.
Then the next cycle starts.
Scrum defines a cyclic process that encourages learning and change. By exposing product increments to the right people, analysing the feedback, and learning from it, we maximise the chances of creating a successful product. If you currently don’t expose your product increments to the stakeholders regularly, then there is a great opportunity to improve your process and your product.
You can learn more about using Scrum to create successful products by attending my Certified Scrum Product Owner training course.
Employing experiments is a powerful technique to facilitate the creation of new products and new features. But to experiment effectively, we need to be clear where innovation takes place and uncertainty resides. Is it the user experience, the business model, or the technologies? Without the right understanding, it’s difficult to ask leap-of-faith questions, formulate meaningful hypotheses, and carry out helpful experiments. This blog posts introduces a simple model that helps you explore where innovation occurs in your products.
I find that product innovation usually occurs in the following three areas: the user experience (UX) and the product features, the business model, or the product’s architecture and technologies. Apple’s first iPhone is an example of a product whose innovation was focused on the user experience and new features such as mobile Internet; the new generation of LED televisions exemplifies technology-driven innovation; and Amazon’s cloud service is an example of business model innovation.
When creating a product with a great user experience, the biggest challenge is to ensure that it is desirable, that the product does a great job for its users and that the user will want to employ it. For business model focussed innovations, it’s developing a sustainable business model, and for technology-driven innovations, it’s dealing with feasibility – applying the new technologies successfully. Desirability, viability, and feasibility hence form three important innovation drivers, as the following diagram shows. The diagram is inspired by the design constraints discussed in Tim Brown’s book “Change by Design”.
For instance, if your product’s competitive advantage is intended to be the user experience then you should aim to understand what makes the product desirable, develop appropriate hypotheses, and employ focussed experiments, for instance, A/B tests to see which feature variant is more attractive to the users. The same holds true for viability and desirability.
When I start to work on a new product, I use the three drivers to understand where innovation occurs and how much uncertainty is present in the development effort. I usually apply the drivers by creating a Product Vision Board sketching the product’s target users and customers, the needs to be addressed, the key features, and the value the product should create together with the product owner and the development team. We then explore and mark the areas of uncertainty.
Here is how this can work in practice: I recently met with the team members of a new product development project of a major UK retailer. The team’s vision was to create new software in order to increase the revenue generated from creating custom solutions for the company’s customers. Together, we created the following product vision board using a piece of flip chart paper and adhesive notes (the details on the notes have been blurred to hide the details):
The two pink stripes indicate the areas of uncertainty and the product’s innovation drivers: UX/features and the business model, and desirability and viability. The former is related to creating a product that does a great job for the company’s sales staff and its customers. The latter refers to the ability to achieve the desired business goals including the revenue increase targeted. The exercise created a shared understanding about the challenges the team was facing, focussed the team’s work, and improved the communication with senior management.
The three innovation drivers help you understand where innovation occurs and where uncertainty is present. This enables you to ask the right questions, formulate appropriate hypotheses, and carry out helpful, focussed experiments.
You can find out more about working with the innovation drivers and the Product Vision Board by attending my Agile Product Management training course.
RSS