Tag Archives: focus

InnovationVsMaintenance

Creating new features and maintaining existing ones are different types of work: The former requires dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Making small, incremental changes entails few unknowns, and the work should be done with minimum effort and no failures or mistakes. I therefore prefer to apply different approaches for the two types of work, as the following picture illustrates:

InnovationAndMaintenance

The picture above shows two workflows: In the upper workflow, a feature team turns new features into a new product version using a cyclic process. In the lower workflow, a maintenance team fixes bugs and carries out small enhancements using a linear process.

The bugs above are taken from: http://yprl.vic.gov.au/sites/default/files/uploads/blogs/mill-park-news/ladybugs.jpg

Separate Teams

To deal with innovation and maintenance work for the same product, I have a preference to work with a feature and a maintenance team, as this creates focus and it reduces task switching. It allows the tem members working on new features to carry out focussed experiments, and it makes it easier for those doing the maintenance work to fix the bugs quickly. If you work with one small team, then consider forming two sub teams – particularly once the maintenance effort consumes more than 25% of the team’s capacity.

A danger of employing separate teams is the creation of a two-class society with the cool feature developer doing rad innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes. To mitigate this risk, the feature and maintenance team members should rotate regularly. This also encourages knowledge sharing and collective ownership.

How often and how many people rotate is best determined on a case-by-case basis. For instance, two to three people could swap places at the end of each week or at the end of each fortnight, depending on which solution best balances team cohesiveness and knowledge sharing.

Separate Processes

Innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the new insights. In other words, the feature team requires an iterative process such as Lean Startup or Scrum. (Please see my post “New Product Development with Lean Startup and Scrum” for a discussion how the two approaches can be combined to create new products and features.)

Making small enhancements and bug fixes, however, does usually not require a cyclic, feedback-driven process, as there is little uncertainty present. Instead, the changes should be implemented and deployed in a fast and efficient manner. A linear, Kanban-based process is ideal for this job in my experience.

As a consequence, you may want to use a Product Canvas to capture the new features, and a product backlog to describe and manage the maintenance work. Similarly, the two teams should use separate boards: one for the new feature development, and one for the maintenance work.

Joint Ownership

While using separate teams and processes for feature development and maintenance work can well be beneficial, separating product ownership is something you should avoid. I have intentionally positioned the product owner between the two workflows in the picture above, as the individual should own the existing product and the new product version. As the product owner, you should hence balance the two concerns and decide how much effort is spent on new feature development vs. maintenance in a given timeframe.

As the product owner, carrying out new feature development and maintenance work in parallel may be your only choice. But maybe you are able to focus on maintenance work for a certain period and do what I sometimes call a “Snow Leopard”: a maintenance release dressed up as a new product version. Use a product roadmap to manage the two types of work across product versions, and to document how much effort you intend to spend on maintenance.

If dealing with new feature development and maintenance is too much work for one person, then consider employing a product owner team with a chief product owner, or break up your product into vertically aligned parts with a product owner looking after one of the newly formed sub-products. Whichever solution works best for you, ensure that there is joint ownership so that both concerns are managed well.

Summary

The following table summarises my recommendations for managing new feature development and maintenance work:

InnovationAndMaintenanceSummary

You can learn more about succeeding with innovation and maintenance work 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.

The Sprint Goal Explained

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

As a rule of thumb, 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.

Sprint Goal Benefits

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.

Supports Prioritisation

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.

Creates Focus and Facilitates Teamwork

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.

Helps Obtain Relevant Feedback

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.

Makes it Easier to Analyse the Feedback

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.

Supports Stakeholder Communication

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.

Writing Great Sprint Goals

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.

Visualising and Tracking the Sprint Goal

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.

Summary

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

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

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

Step 1: Analyse the Feedback

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

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

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

Step 2: Integrate the Learning

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

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

Step 3: Decide what to do Next

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

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

Step 4: Create Small Stories

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

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

Step 5: Get the Stories Ready

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

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

Leverage Teamwork

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

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

Summary

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

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

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.

Context Diagram with Epics

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.

Activity Diagram with Stories

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 Story Modelling Tips

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:

  1. Model collaboratively: User story modelling serves to create a shared understanding of the desired product functionality. Use context and activity diagrams to capture the essence of a conversation, not to replace it! Create and update your diagrams collaboratively involving the team and as appropriate, the stakeholders.
  2. Focus: Apply modelling selectively and only describe relevant aspects. Focus on the relevant product backlog items and leave out the rest. Don’t include too much information or unnecessary details.
  3. Keep it simple: Keep your diagrams simple and easy to understand. Rather use additional diagrams to illustrate further aspects than cluttering a model with too much information. Complex diagrams are usually not helpful.
  4. Use whiteboards and flip charts rather than electronic tools. Simple, physical tools encourage participation and collaboration. They avoid the impression of perfection and completion.

Summary

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.

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


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

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

Enter the Product Backlog Board

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

The Product Backlog Board (click to enlarge)

The product backlog board depicted above provides the following elements:

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

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

The Story Area

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

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

The Constraint Area

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

The Model Area

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

Making the Information Visible and Accessible

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

The Product Backlog Board on an Office Wall

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

Stocking the Product Backlog Board

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

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