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 in a Nutshell

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:

1. It’s Tuesday morning, and Mary is working on her computer. She wants to book Roger Smith on a public Certified Scrum Product Owner course taught by Roman.
2. Mary visits romanpichler.com and chooses a public CSPO class.
3. She enters the participant information including first name, last name, email address, special dietary requirements.
4. She then chooses a payment option and enters the payment details.
5. Mary accepts the terms and conditions, and confirms the booking.
6. Mary sees that her booking has been successful. After a short while, Roger receives an email confirmation with the booking details.

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 Summarised

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.

What about User Stories?

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.

Summary

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.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

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.

The Planning Levels

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:

The Vision

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

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

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.

Product Planning Tools

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.

Summary

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.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

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.

Discovering Nonfunctionals

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.

Describing Nonfunctionals

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.

Summary

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.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

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 Good

A 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 Bad

While 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 Ugly

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

Conclusion

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.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

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.

Be Clear on your Research Goal

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.

Invite the Right People

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.

Explain what the Product does for the User

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.

Engage in a Dialogue

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.

Take Notes

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.

Separate Research from Analysis

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.

Understand the Limits of the Product Demo

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.

Summary

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.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler