Tag Archives: learning

SprintGoalTemplateFeaturedImage

I find it helpful to consider three questions when choosing a sprint goal: Why do we carry out the sprint? How do we reach its goal? And how do we know that the goal has been met? My sprint goal template therefore consists of three main parts: the actual goal, the method employed to reach the goal, and the metrics to determine if the goal has been met. It additionally provides a header section that allows you to state to which product and sprint the goal belongs, as the picture below shows. You can download the template as a PDF from romanpichler.com/tools/sprint-goal-template/ or by clicking on the image below.

RomansSprintGoalTemplate

The template above has grown out of my experience of working with Scrum for more than ten years, and it is inspired by the scientific method and Lean Startup. Let’s have a look at the template sections in more detail.


The Goal Section

The goal section states why it is worthwhile to undertake the sprint. Examples are:

  • Test an assumption about the user interaction and learn what works best for the user, for instance: “Will users be willing to register before using the product features?”
  • Address a technical risk such as: “Does the architecture enable the desired performance?”
  • Release a feature, for instance: “Get the reporting feature for general release.”

The sprint goal hence differs from listing the user stories that should be implemented. It communicates the reason for carrying out the work, and it provides a motivation for running the sprint. The sprint goal should be shared: The product owner and the development team should believe that working towards the goal is the right thing to do.

To choose the right sprint goal I find it helpful to consider the amount of uncertainty present. In the early sprints, addressing risks and testing assumptions allows me to learn about what the product should look like and do and how it is built. Once the key risks and critical assumptions have been dealt with, I like to focus on completing and optimising features, as the following picture shows:

ChoosingTheRightSprintGoal


The Method Section

This section addresses the question of how the goal is met. The default Scrum answer is simple: Create a (potentially shippable) product increment using the high-priority product backlog items, and demo it to the stakeholders in the sprint review meeting. But writing software and employing a product demo are not always the best methods to achieve the goal! A paper prototype can be good enough to test a visual design idea or an assumption about the user interaction, for instance. What’s more, other methods such as carrying out a usability test or releasing software to run an A/B test may well be more effective than a product demo. You should therefore carefully choose the right method and state it in this section.

But don’t stop there. Determine the test group, the people who should provide feedback and data. Who these individuals are depends on the sprint goal: If you are validating an assumption about the visual design, the user interaction or the product functionality, then you probably want to collect feedback and data from the users. But if you are addressing a technical risk, then users may not be able to help you. Consider inviting a senior developer or architect from another team instead. Stating the test group clarifies who “the stakeholders” are, who is required to provide feedback so that the right product is developed.


The Metrics Section

The metrics section communicates how you determine if the goal has been met. Which metrics you use depends on the method chosen. For a product demo, you may state that at least two thirds of the stakeholders present should respond positively to the new feature, for instance; for a usability test, at least three of the five testers are complete the task successfully in less than a minute; and for the release of a new feature, you might say that at least 80% of the users use the new functionality at least once within five days after launching the feature.

Whichever metrics you choose, make sure that they allow you to understand if and to which extent you have met the goal.


The Header Section

The header section consists of the two subsections “Product” and “Sprint”. They simply allow you to state which product and which sprint the goal belongs to.

Customise this section according to your needs. If you work for an agencies or an IT solution provider, you could replace “Product” with “Project”, for instance.


User Stories and the Sprint Goal

You may be wondering how the template relates to the user stories. Let me first reiterate that your sprint goal should differ from your user stories. The goal explains the why it is a good idea to carry out the sprint an implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two.

To connect the template and the stories you have two options: You can state the relevant user stories in the template’s method section, or you can list them separately on the sprint backlog, as the following picture illustrates.

SprintGoalAndSprintBacklog

In the picture above, the sprint goal is stated on the left to the sprint backlog, which lists the user stories and the tasks required to meet the goal in form of a task board.


Learn more

You can learn more about choosing effective sprint gaols and applying the sprint goal template by attending my Certified Scrum Product Owner training course. I have written in more detail about sprint planning in my book “Agile Product Management with Scrum”. Please contact me for onsite and virtual product owner training.

10PersonaTipsFeaturedImage

1. Start with Provisional Personas

As its name suggests, a provisional persona is not a fully-fledged, detail rich user model, but a first version that is good enough to start discovering the right user experience and the right product features. Working with sketchy but good enough personas is particularly helpful in an agile and lean context where we want to very quickly test our assumptions, rather spending a lot of time with upfront market research.

To get started, learn enough about the users and customers by employing, for instance, direct observation and problem interviews. While your initial personas can be sketchy, they should be based on market insight and nor speculation. With your provisional personas in place, gather feedback on prototypes, product increments, and MVPs to validate and adapt your personas. As you run more iterations, your personas should become more refined. The following picture illustrates this process:

ProvisionalPersonaProcess

Note that provisional personas are different from proto-personas, as defined by Jeff Gothelf, as proto-personas are not necessarily based on user research.
 

2. Keep your Personas Concise

It’s easy to add more and more detail as you create your personas: Enriching the description and adding, for instance, another cool spare time activity or a cute pet can be so much fun. While your personas have to contain enough information to be usable, too much detail bloats them, and they become difficult to work with.

Only include information that is relevant, that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest. My simple, minimalist persona template wanst to help you write concise personas (you can download the template by clicking on the picture):

RomansPersonaTemplate

3. Distinguish User and Customer Personas

Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see.

Say we want to develop a new, advanced X-Wing Fighter. The pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Rebel Alliance is likely to be concerned with the purchase price and the maintenance cost. Employing two different personas allows us to model the user and the buyer, and to state their different goals.
 

4. Choose a Primary Persona

Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, the pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal – creating a plane that’s easy to fly and well protected – becomes our top priority. But if we choose John, the purchase guy, as the primary persona, then the resulting product would be very different.

PrimaryPersonaLuke

5. Make your Personas Believable

Your personas should help the development team cultivate empathy for the users and customers, and to view the product from the user’s perspective. To achieve this, your personas have to be believable. There are three practices that help you create believable personas:

  • Base your personas on user research.
  • Respectfully choose a persona’s name, picture, and characteristics.
  • Refine personas together with the development team.

 

6. Identify the Main Benefit or Problem

I frequently see personas that contain a lengthy list of problem and benefit statements. While is it is perfectly OK that a persona description provides more than one problem or benefit, I recommend selecting one main problem or benefit – the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making.
 

7. Test your Personas

Validate your persona descriptions, as you lean more about the users and customers and their needs by building prototypes, product increments, and MVPs. This is particularly useful in an agile and lean context, where you want to minimise the amount of initial market research to quickly test your crucial ideas.

Adjust and refine your personas when you decide to persevere. But rewrite your personas or start with brand-new ones if you have to pivot and change your strategy.
 

8. Connect Personas and User Stories

Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover. The following format helps you connect your personas with your user stories:

StoryTemplate

9. Visualise your Personas

Make you personas visible and accessible to everyone involved in the development effort. I find working with paper-based personas very beneficial, and I like to put them on the Product Canvas.

PersonasOnTheProductCanvas

10. Recognise when Personas are not Appropriate

While personas are a powerful tool, there are instances when they are not appropriate. If you create a product that serves a small user group, then working with personas not be necessary. Similarly, if your product does not have any end users, the employing personas is not advisable.

Take a client of mine that develops a physics engine, software responsible for the clever animations in computer games. The users of the software are games developers who integrate the engine into their code. Creating personas for the physics engine is not beneficial in my mind. But for the entire game it is, of course.


More Information and Help

You can learn more about working personas in an agile and lean context by attending my Certified Scrum Product Owner an Product Canvas training course. The courses are also available for onsite delivery. Please contact me for more information.

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.

Learning Vs Execution

Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals.

Learning vs. Execution

When we start developing a new product or new features, there are usually more unkowns than knowns, more things we don’t know than we know: We may not be clear on the user interaction, the user interface design, the product’s functionality, or the architecture and technology required to build the product. Our greatest challenge is therefore to deal with the uncertainty present, and the associated risks.

As a consequence, the early sprints should focus on creating the relevant knowledge, and addressing the key risks. Selecting a testable idea (hypothesis), and running an experiment are great ways to achieve the necessary learning. As testing ideas results not only in success but also in failure, you should expect to fail in the early sprints. Your Product Canvas or backlog, and your architecture are likely to see bigger changes driven by the newly gained insights.

As you acquire more knowledge, your focus should gradually shift from resolving uncertainty towards execution: building a product that is ready for general release. Rather than primarily testing ideas, you should now start completing features and incrementally adding new ones. Failure can still happen at this stage, but it is usually a sign that something has gone fundamentally wrong. Similarly, your Product Canvas or backlog should have started to stabilise and exhibit less volatility. The change of focus may also impact your Definition of Done: Throwaway prototypes used to test ideas quickly don’t have to have the same quality as software that will be shipped. You can now start ramping up the project, add new teams, and consider employing distributed teams.

The following picture visualises the relationship between learning and execution for the development of a new product or a new product version:

To understand how much learning and experimentation is required, consider the amount of innovation present and the technologies used: A brand-new product usually requires more experimentation than a product update; and a web app developed with standard technologies is faster and easier to create than an embedded system or a mainframe application (assuming that some market research or problem validation has already taken place).

Benefits

Understanding the relationship between learning and execution has three main benefits:

First, it allows you to set and manage stakeholder expectations. It helpful for the stakeholders to understand that the early product increments are likely to be throwaway prototypes, and that failure is to be expected in the first few sprints.

Second, it helps you choose the right sprint goals, and focus the work of the development team: Your early sprints should acquire the relevant knowledge by carrying out experiments. You later sprints should build features and get the software ready for general release.

Third, it makes it easier to select the right research and validation techniques. You may want to work with user tests and product demos in your early sprints, and with releasing software to selected users in the later ones.

Summary

Innovation – creating a new product or new features – involves uncertainty and risk. To build the right product with the right features quickly, you should make a concentrated effort in your first few sprints to quickly address the key risks and acquire the relevant knowledge. Then shift your focus to completing features and adding new ones by creating software that can be released.

You can find out more about learning and execution in Scrum by attending my Certified Scrum Product Owner training course.

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.