When I teach product owners I ask what qualities the product backlog should fulfil. More often than not, a key property is missed: emergence. This corresponds to my experience of how product backlogs are commonly used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be dynamic. It should continuously evolve based on customer and user feedback thereby facilitating the discovery of the right product features, as this blog posts explains.
At the beginning of a new product development projects, there are many unknowns, and we often do not know what the product should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements. We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to better understand how we can best solve the customers’ problem, and what the product should really look like and do.
To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required in your backlog, as the following diagram illustrates:
When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request.
Analyse the feedback carefully with your product vision in mind. Ask yourself if the feedback is helpful turn the vision into a great product – assuming that your vision is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with customers and users.
Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness.
If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed.
Keep the majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my product backlog board and to capture ideas as epics. Identify the epics that exhibit risk and uncertainty, and select the ones you want to test with the next product increment. Then derive small stories from the epics and make them high priority.
Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements of a new product can be correctly determined upfront. We stand a better chance of success by using early and frequent feedback from customers and users to validate our ideas. As Ken Blanchard says: “Feedback is the breakfast of champions.”
With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.
A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.
The Scrum Startup
The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.
We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a product vision and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.
We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.
Setting up a Scrum team as a startup is so powerful as it disentangles the team from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.
The Scrum Startup and the Enterprise
The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.
Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.
Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.
As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.
Scrum Startup and Collaboration
When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.
To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the startup organisation should be stable. The following diagram depicts the four qualities:
Desirable Qualities of a Scrum Startup
While the Scrum team should be loosely coupled to the rest of the organisation, it still requires its support, for instance, its financial support, its sales force, and its marketing knowhow. Being in control of the product implies that the product owner is empowered to decide when which functionality is released and how to act on feedback received. The development team must be in charge of their development and test environment. The software should be largely self-contained with few dependencies to other products. Having a personal stake in the outcome of the development effort may include a bonus, stock shares, awards, or some other incentive. Last but not least, the Scrum team should be stable and experience few changes to its composition: Stable teams facilitate effective teamwork and learning.
Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as a startup can facilitate product and process success. Give it a go.
I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test the vision as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.
With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum. But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?
This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.
“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction. But every vision is a hypothesis: It contains assumptions about the future product including the target group, the needs the product will address, a sketch of the product, and the value it should create for the organisation developing and selling it. (See my vision board for a handy tool to capture and display the relevant information.) These assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to target customers and users.
Unfortunately, the product vision is often too coarse-grained to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the vision. The corresponding items are then placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product vision; it makes the vision implementable.
Vision and Backlog
Once we have a vision and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the feedback.
Vision, Backlog and MVP
Note that releasing the MVP can be limited to a small group of customers and users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. An example where internal releases did not work so well is Google Buzz: The software was apparently loved by Google engineers but unfortunately not by the rest of the world.
Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions made in the vision – which is likely to be the case when a new product is developed – we should adjust the vision and the product backlog. We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the vision can require restocking the backlog – depending on how much the vision has changed. We then continue with the next cycle, develop a new MVP, and gather new feedback.
The Vision is Invalid
If the feedback confirms the vision, we adapt the product backlog, for instance, by adding new requirements that help us turn the vision into a successful product. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.
The Vision is Valid
Validating the product vision using a minimal viable product is a powerful concept that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations.
Many thanks to Stefan Roock for feedback on the MVP of this post.
Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when the two alternatives are appropriate together with their advantages and challenges.
One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider – a member of the marketing group should take on the product owner role. This approach is illustrated by figure 1:
Figure 1
Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs.
Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past (“IT never delivers”).
Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who listens to the ideas and requirements of the customers and users but decides when which features are released. Figure 2 summarises this option:
Figure 2
For comercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role. Note that figure 2 illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented.)
Advantages: Separating the customer and the product owner role helps create a product that addresses all the needs selected. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively.
Challenges: Empowerment of the product owner can be difficult to achieve: Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners.
I recommend that you apply one of the patterns described above to each of your products. To put it differently, a product should either be managed by a customer or by a customer proxy. But there is no reason why you cannot mix and match the two patterns across your portfolio: Choose customer product owners for bespoke products and customer proxies for products that serve several customers.
To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! No market research technique can deliver a forecast that is 100% accurate. And in the case of disruptive innovations, it’s not possible at all to make a sound prediction, as Clayton Christensen observes in his book The Innovator’s Dilemma: “Markets that do not exist cannot be analysed.” Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched.
A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right.” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand.
An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users.
Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed.
To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers.
Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a bland, boring or simplistic product. It means focusing on those properties that are essential for the product success. If you work with user stories, for instance, review each story or epic, and ask yourself if the product can be shipped with out it. If yes, exclude the story. As the French writer and poet Antoine de Saint-Exupery put it:
“Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.”
“Words are but sound and fury,” says Macbeth, and there are several similar but confusing terms to denote minimal products. My termminimal marketable product is a reference to Mark Denne and Jane Cleland-Huang’s work. In their book Software by Numbers they coin the term minimal marketable feature set to denote the smallest amount of functionality creating value for a customer. As I view a product as more than a set of individual features, I prefer to talk about products rather than feature sets. The idea of quickly delivering a small set of features and enhancing the software incrementally dates back to Tom Gilb’s evolutionary delivery method developed in the 1980ies by the way.
Eric Ries has more recently popularised the term minimal viable product, which he defines as “the product that allows a team to collect the maximum amount of validated learning about customers with the least effort.” Based on this definition, the minimal marketable product may or may not be the minimal viable one. Independent of the differences, all terms share the idea to quickly launch an initial product to learn from the market response, and to adapt the product accordingly. And that’s what matters.
Determining the launch date and the budget before development starts can be tricky in Scrum. Relying solely on Scrum’s empirical approach, a team working on a new product has to carry out at least one sprint to measure the velocity and to understand the rate of change in the product backlog. For many organisations this is difficult to accept, as an investment decision is often required before the development work can start.
Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent customer and user feedback.
Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. This blog post discusses how we can determine the launch date and the project budget before the first sprint – without turning the product backlog into a disguised requirements specification.
A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the team, and stakeholder representatives including a management sponsor or the customer should attend the workshop. A shared product vision and an initial product backlog now have to be in place. The former paints a rough picture of the future product, scopes the project, and acts as the shared overarching goal. The latter sketches the outstanding work necessary to develop the product. Make sure all attendees understand and buy-into the vision.
Based on the product vision and the backlog, we determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits. If the date is missed, the opportunity is gone, and launching the product no longer makes sense. The work carried out to create the vision helps us identify the window of opportunity and understand if the product can be developed and launched within the window selected; we leverage the insights gained from the initial market research and technical exploration work. The beauty of this approach is that it does not require having all requirements described in detail in the product backlog. But it assumes is that the vision stays stable for the duration of the development effort.
Once the window of opportunity and a delivery date have been identified, we can determine the budget. To do so, we ask ourselves who is required to work on the project, which skills are needed and how many teams may be required. We then add additional items such as licensees for tools and third-party software. This provides us with an initial budget.
Understanding the timeframe and the budget and having the sponsor or customer present, should allow us to make a go/no-go decision in the release planning workshop, and in the latter case to discuss if and how the vision and the product backlog should be adapted. Making a decision in the workshop does not only create transparency and leverage the input of the attendees. It also avoids waiting and delays and helps reduce time-to-market.
Once development is underway, we capture the progress at the end of each sprint in form of a release burndown chart and create a forecast for the reminder of the project. This validates the original plan. It allows the product owner to steer the project and to trade off time, budget and functionality. Note that quality is frozen in an agile context and must not be compromised. Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently.
Using a collaborative release planning workshop and determining the window of opportunity facilitates an early investment decision and the emergence of requirements. It frees agile teams from having to describe most product backlog items in detail at an early stage, and it avoids having to carry out one or more sprints before a date and a budget can be established.
User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.” By focusing on a distinct area of functionality, the story allows the team to understand, implement, and test the requirement. This strength is also a weakness: User stories are not well suited to express the relationships between different features and to describe workflows.
To show how different stories fit together, I have found it useful to complement user stories with lightweight models, originally invented for use cases: context and activity diagrams. I also add important diagrams to the product backlog, as I explain in my post The Product Backlog Board.
A context diagram that depicts user roles and epics, large and coarse-grained stories, is great to provide an overview of the product’s functionality. Let’s have a look at an example, a diagram that sketches an online application store called “Application Centre”:
The diagram above depicts three user roles: provider, user and administrator. It shows how the roles interact with epics that describe Application Centre functionality. It tells us, for instance, that the user and the administrator both review applications – to enable end user and staff ratings.
Note that the diagram does not list all epics contained in the product backlog, and it does not state all user roles. It rather focuses on the product backlog items relevant for a conversation between the product owner and the team, or the Scrum team and the stakeholders. This results in a diagram that is simple and easy to understand rather than complex and overwhelming.
To get a job done, users often carry out several steps and interact with different pieces of functionality. Activity diagrams are great at capturing sequences and workflows by connecting individual user stories. They also support the creation of complex test scenarios that go beyond a single story.
Let’s have a look at an example, a diagram that elaborates the epic “Register” on the context diagram above. It shows the key steps required for a user to register with the Application Centre:
The diagram above visualises the steps of the registration workflow by connecting three individual stories. It starts with stating the details of the provider company, continues with entering a user name and password, and if successful, accepting the usage terms and conditions.
User stories modelling is a handy tool in the product owner’s toolbox. But like any tool, it wants to be applied properly. The following tips help you create great diagrams:
Collaborative, lightweight and focussed user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories, put them in a context and connect individual epics and stories. Any model related to user stories and epics should be the outcome of a conversation – and never replace it.
The product vision plays an important role in bringing a new product to life: It captures what the product should roughly look like and do, and why it should be created. It acts as the shared, overarching goal guiding everyone involved in the development effort. As the vision is so vital, teams need a tool that helps them create and capture their vision. This post introduces such a tool.
I’ve named the tool that I use Product Vision Board. The board allows the product owner and the team to map out the key aspects of their idea, as the following diagram illustrates:
The Product Vision Board
Here is a sample board that contains two personas, three scenarios, a card with the product’s top three features, an user interface and an architecture sketch, and a business model sketch (loosely based on the business model canvas):
A Sample Product Vision Board
As the above diagram illustrates, the product vision board is most effective when put on the office wall where everyone can see it. Simply add the artefacts you create to the board while investigating the four product aspects. If you work on a distributed project, post a picture of the vision board on your wiki or replicate it in an easily accessible electronic spread sheet.
Don’t fall into the trap of specifying all features upfront: Select only those features that are crucial to address the selected customer and user needs and that significantly influence the product success. The same is true for the product and user interface design: Focus only on the most critical aspects, and discard the rest for now. Additional requirements and the detail design will emerge later and are best captured on the product backlog board. And while it is helpful to reflect on the value the product should create for the organisation developing and selling it, providing a detailed business model and a firm business plan for a new product is often not feasible. Finally, test your vision quickly by creating a prototype or product increment (minimal viable product), exposing it to target customers and users, and analysing their feedback. This is likely to result in changes to your vision, particularly if you create a new, innovative product.
“Which project is best suited to pilot Scrum?” is a question I get regularly asked in my workshops and training courses. While it is always important to carefully consider the specific situation of an organisation, I have found the following six criteria helpful to select the right agile pilot project:
Before you now select your pilot project or decide to delay experimenting with agile practices, consider the following advice:
“What I hear, I forget.
What I see, I remember.
What I do, I understand.“
~ Confucius ~
Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to many hundred items. Many backlogs don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible.
How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of “features, functions, technologies, enhancements, and bug fixes,” as Schwaber and Beedle (2002) write. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.
I have therefore started to work with a structured and hierarchical product backlog, which I have named “Product Backlog Board.” Here is a sample product backlog board:
The Product Backlog Board (click to enlarge)
The product backlog board depicted above provides the following elements:
I am not the first person to recognise that flat product backlogs can be inappropriate; Jeff Patton did so a few years ago when he developed his story maps, for instance. You could even use a story map within your product backlog board if you wanted.
The story area is divided into two sections: items that are likely to be worked on in the next sprint, and the other outstanding work that is essential to create a successful product. The items in the ready section must be clear, feasible and testable. They are preferably captured as small and detailed user stories with well-written acceptance criteria. The epics, however, are coarse-grained and sketchy. They are placeholders for future detailed stories which are progressively derived from them. Epics are grouped into themes with each theme representing a product capability.
The stories in the ready section must be strictly prioritised, from one to n, to focus the work of the team. You don’t have to order the themes and epics unless you want to indicate when functionality will be released, for instance, in form of an early product increment (beta). But don’t forget to review the epics on a regular basis, and consider risk and uncertainty as well as dependencies. This will help you to decide how to stock the ready section and to determine which stories have to be carved out of your epics.
This area contains the global non-functional requirements of the product – operational qualities as well as product design and user interface requirements that apply to the entire product. It’s important to recognise and address these constraints: They influence the user experience, drive architecture and the technology decisions, impact the total cost of ownership and the product’s life expectancy. I prefer to capture operational qualities using constraint cards. The critical aspects of product and user interface design are best described visually as sketches or screenshots of mock-ups and prototypes. Note that the items in the constraint area are not estimated. Instead, the definition of done states that all constraints must be fulfilled.
Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by showing how the user roles interact with the epics. The same is true for workflows: It’s often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience. If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board. Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and workflows in more detail in my post on user story modelling.)
The product backlog should be visible and easily accessible for everyone involved in the development effort. I hence prefer to work with a physical product backlog board – paper cards and paper sheets put up on a large board or an office wall.
The Product Backlog Board on an Office Wall
On distributed projects the product backlog board can be easily stored as an electronic spreadsheet. Just remember to make it visible, for instance, by posting it on the project wiki.
I prefer to derive the contents of the product backlog board from the product vision or the product roadmap and to focus its content on the items that are essential to develop the next product version or the next major public release. This reduces complexity, creates clarity, and avoids predicting an uncertain future.
When you stock the constraint area, resist the temptation to create the complete product and user interface design upfront. Rather focus on those aspects that significantly influence the success of the product and that are difficult to change at a later stage. The detailed design should evolve from sprint to sprint based on customer and user feedback.
Using the product backlog can be challenging, and many product owners wrestle with overly long and detailed backlogs. The following ten tips help you use your product backlog effectively.
Let me know if these tips are helpful for you, and what other guidelines you follow when you work with your product backlog. I look forward to your comments.
I am currently rewriting this blog posts by combining principles from Lean Startup and Scrum. I am planning to have the reworked version online by the end January. I am sorry for the inconvenience. Please check back later.
“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back.” Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for eight hundred years to find out. A few minutes will do.
The requirement that the product backlog items to be worked on in the next sprint must be “ready” or “workable” is already mentioned in the first Scrum book published in 2002. But it has been emphasised more recently particularly by Jeff Sutherland. Some even talk about a “definition of ready” – even though strictly speaking, there is only a definition of done in Scrum. The idea is that a ready item can be pulled into the sprint by the team and confidently turned into a product increment – software that is “done,” as the following diagram illustrates.
Ready and Done
Little has been said though about what ready exactly means – what the qualities are the high-priority items have to fulfil. I write in my book Agile Product Management with Scrum that a “ready” item should be clear, feasible and testable. These qualities do not apply to user stories but also to all other backlog items, no matter how they are described.
A requirement is clear if all Scrum team members have a common understanding of what it means. Collaboratively describing requirements, for instance, in a weekly product backlog grooming workshop, and expressing high-priority backlog items as detailed user stories with acceptance criteria facilitate clarity.
An item is testable if there is an effective way to determine whether the requirement is satisfied within the sprint in which it is implemented. Acceptance criteria ensure that each story can be tested.
A requirement is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. To ensure feasibility requirements are progressively decomposed until they are small enough. I prefer to work with stories that can be implemented and tested within a few days, as this allows the product owner to provide feedback on the software during the sprint thereby increasing the likelihood that the team builds the right product increment.
To determine an item’s complexity, you should consider its uncertainty and its dependencies on other items. If a story is constrained by a user interface requirement, for instance, it must be clear what the resulting product increment should look like. If that is not the case, the team should explore the user interface requirement before the story is implemented. If exploring the item requires a large effort, the exploration should be tackled in a separate sprint, for instance, by implementing a throwaway prototype to investigate the user interface design.
“A Jedi must have the deepest commitment, the most serious mind,” continues Yoda in the Star Wars episode. Similarly, you should be committed as the product owner to making the high-priority product backlog items clear, feasible and testable before sprint planning starts. This facilitates an effective meeting and a firm commitment.
Remember: A sprint is a function that takes high-priority requirements and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.
The following list is a tongue-in-cheek collection of common mistakes in applying Scrum. They all influence product success negatively. Combined they are a recipe for certain failure.
To avoid the mistakes above and to learn how to create great products with Scrum, refer to my book Agile Product Management with Scrum, or book yourself on one of my product owner trainings.
The following diagram provides an overview of the product owner role: It summarises the role’s responsibility, main duties, key artefacts, and constraints. To understand the role, I find it helpful to view the product owner as an entrepreneur or intrapreneur.
Related blog posts:
Demystifying the product owner role
Two common ways to apply the product owner role
Scaling the product owner
Avoiding common product owner mistakes
Desirable characteristics of a product owner
Product owner = product manager?
Business analysts in Scrum
RSS