Tag Archives: user stories

Scrum, XP and Lean

Splitting User Stories

2 Comments

A common challenge faced by inexperienced Scrum teams is related to splitting user Stories (in Scrum, Product Backlog Items or PBIs) so that they are granular enough for development. The INVEST model is a good way to test whether user stories are well-written.

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

Independent – Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.

Negotiable – The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.

Valuable – Each user story must add business value to the product, the customer and/or the users’ experience.

Estimable ¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.

Small – A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.

Testable – Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.

Vertical vs Horizontal Splitting

There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment each sprint.

Splitting User Stories Example

As a customer I can pay for my order so that I receive the products

If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…

As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.

And/or

As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.

The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.

Breaking down by Workflow

Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:

As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.

As a customer I can provide my banking information for my order so that I can receive the products I ordered.

As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.

Other Methods

There are many other methods that can be utilized to breakdown larger user stories such as:

  • Breaking down by business rules
  • Breaking down by happy / unhappy flow
  • Breaking down by input options / platform
  • Breaking down by data types or parameters
  • Breaking down by operations (CRUD)
  • Breaking down by test scenarios / test case
  • Breaking down by roles
  • Breaking down by ‘optimize now’ vs ‘optimize later’
  • Breaking down by browser compatibility

Kudos to this article for inspiring the list above: blog.agilistic.nl.

Other Helpful Resources

The Hamburger Method
User Stories and Story Splitting at AgileAdvice.com

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Engineering, How-To Apply Agile, Professional Development, Reference Information

Summary of User Stories: The Three “C”s and INVEST

1 Comment

User Stories

Learning Objectives

Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.

Consider the following

User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.

The Three ‘C’si

A User Story has three primary components, each of which begin with the letter ‘C’:

Card

  • The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
  • The Card is usually follows the format similar to the one below

As a <user role> of the product,

I can <action>

So that <benefit>.

  • In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.
  • Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.

Conversation

  • The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
  • As much as possible, this is an in-person conversation.
  • The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
  • This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

Confirmation

  • The Product Owner must confirm that the story is complete before it can be considered “done”
  • The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
  • Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team.  All associated acceptance tests should be in a passing state.

INVESTii

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:

I – Independent

  • The solution can be implemented by the team independently of other stories.  The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.

N – Negotiable

  • The scope of work should have some flex and not be pinned down like a traditional requirements specification.  As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.

V – Valuable

  • The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals.  This does not mean that a single user story needs to be a marketable feature on its own.

E – Estimable

  • The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality.  This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.

S – Small

  • The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog.  This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.

T – Testable

  • Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.

Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.

Splitting Stories:

Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:

  • Split by process step
  • Split by I/O channel
  • Split by user options
  • Split by role/persona
  • Split by data range

WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.

Personas

Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii

Each of our fictional but specific users should have the following information:

  • Name
  • Occupation
  • Relationship to product
  • Interest & personality
  • Photo

Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:

<persona>

can <action>

so that <benefit>.

 

i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.

ii INVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Professional Development, Reference Information, Theory of Agile

Tips to Start Agile in a Hostile Environment

3 Comments

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally.  In some cases, management may even be hostile to the concepts and practices of Agile methods.  If you are interested in Agile, you don’t have to give up hope (or look to switch jobs).  Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile.  In some ways, this is also the easiest practice to introduce into an organization.  Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“.  These are retrospectives that can be done in 15 minutes or half an hour.  Try to do them with your team weekly.  If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting.  If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective?  Because it’s a high return-on-investment activity.  For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning.   Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start.  Myself, my first formal Agile environment, I started with the Daily Scrum.  Another time less formal, I started with Test-Driven Development.  In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months.  This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders.  This is the practice-by-practice approach.  Start with a simple Agile practice that you can do without asking anyone for permission.  Make sure it is a practice that makes sense for your particular environment – it must produce some benefit!  If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start.  If you are more business-oriented, then maybe consider user stories or one of the Innovation Games.  If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another.  If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy.  This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”.  This is an opportunity to do Agile.  Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.”  There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support.  In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it.  Don’t talk about it.

The “just do it” approach requires that you have some influence.  You don’t have to be an influencer, but you need connections and you need charisma and you need courage.  If you don’t have at least two of those three, you shouldn’t try this approach.  You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works.  Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels!  If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work.  Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans.  Of course, you need to actually execute some of your plans.  Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages.  Lacking that trust will slow everything you do possibly to the point of ineffectualness.  Trust means that you have, for some time, a formal vow of silence.  Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough!  Read “Fearless Change” by Mary Lynn Manns and Linda Rising.  This is a “patterns” book.  It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use.  Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent.  Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item.  Instead, this is a preventative measure… to prevent negative reactions to your proposals for change.  The words “Agile” or “Scrum”, while they have their supporters, also have detractors.  To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names.  Use another name.  Or let your ideas go nameless.  This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”.  By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”.  Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program.  It’s a 40-week program that takes about 12 hours/week of your time for coursework.  The next cohort of participants starts in June 2015 and we are taking deposits for participants.  This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Professional Development, Scrum, XP and Lean

Full-Day Product Owner Simulation Exercise

Leave a comment

This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it.  My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise.  It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class.  I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.

UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!

UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.

NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

Pre-requisites: None!  No prior Scrum or Agile knowledge or experience required.  However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.

Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.

Timing: This simulation takes at least 7 classroom hours.  I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.

Materials Needed:

  • Coloured pencils and/or coloured markers
  • Black Sharpie fine-point markers
  • Scissors
  • Rulers
  • Scotch tape and/or glue stick
  • Blank white printer paper
  • Pencils, erasers, pencil sharpeners
  • Blank white 4×6 and 3×5 note cards
  • Blank white box (e.g. a shirt box from U-Line) or foam core boards (see photo)
  • Planning Game cards (email me if you want a bunch for free!)

Product Owner Simulation - Product Box Example

Room Setup: Round tables with 5 to 7 chairs at each table.  Materials distributed to each table.

Product Owner Simulation Agenda

(with facilitator’s notes in red)

Introduction to the Product Owner Simulation

  1. Lecture: Simulation Overview, Backlog Preparation and Refinement
    The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint.  Many of the techniques we explore will also be useable in ongoing Product Backlog Refinement.  Review the agenda with participants.
  2. Exercise: Great Products and their Vision
    5 minutes – at table groups, think about the physical consumer products you know and use often.  How are those products marketed and sold?  How are they presented?  How do you decide to use that product vs. a competitive product?  Make sure you discuss specific products rather than corporate brands or product categories.
  3. Discussion: What Makes a Great Product Vision?
    Ask for the group to brainstorm the qualities of a great product vision.  Ensure that “simplicity”, “urgency”, and “emotion” are all mentioned.  (Great reference: “Made to Stick: Why Some Ideas Survive and Others Die” by Chip and Dan Heath.)
  4. Discussion: Choosing a Product for the Simulation
    Give participants three product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons’ medical and practice management”, “POS for food trucks with social features”).  A table group must agree to one of the options.  They will stick with this product for the remainder of the simulation.  Three minutes to decide.

Product Vision

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

  1. Exercise: Product Vision Statement
  2. 5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”. The audience of the product vision statement is your Scrum Team (NOT customers).  Debrief by hearing from each group, then asking if the three characteristics have been communicated.
  3. Handout: Product Vision in Context [PDF]
  4. Lecture: Explain the Product Vision handout and ask for questions, insights.  At this time, highlight the differences between a “product” and a “project”.  Emphasize the concept that a product has customers who pay money and who have choice about what they buy, and that those customers are outside of your organization.  Possible discussion about Scrum being ideally suited for Product Development vs. project management or operations.
  5. Reference: Innovation Games – Product Box [site]
  6. Handout: Product Box Innovation Game [PDF]
  7. Lecture: Product Box
    Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog.  Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick).  Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections.  Use of online resources / web research is allowed but should not dominate the exercise.
  8. Exercise: Building Your Product
    30 minutes, with warnings at 15 minutes and 5 minutes remaining.  Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
  9. Exercise: Presenting Your Product
    5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
  10. Discussion: Debrief Product Box
    Focus on feasibility of using Product Box in real life, the power of metaphor, and the power of collaboration.
  11. Exercise: Product Vision Statement Reprise
    5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”.
  12. Discussion: Debrief by hearing new Product Vision Statements.

Product Users

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

  1. Handout: User Categories Thinking Tool [PDF]
  2. Lecture: User Categories
    Describe “users we sell”, “users who pay” and “admin users” as the three major categories.  Users can be in hierarchies where a general user type may have two or more specific sub-types.
  3. Exercise: Identifying Users
    10 minutes.  One user of each main type, at least 5 users in total.  More is okay.
  4. Handout: Persona [PDF]
  5. Lecture: Personas, Usability and Empathy
    Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper).  Usability as part of Agile, not separate (i.e. “working software”).  Identifying personas as a way to build empathy from the development team to the end users/customers.
  6. Exercise: Generate a Persona
    10 minutes.  Choose a primary user.  Generate name, age, background story, and relationship to product.  Find an image from a stock photography site.  Important: do at least a little bit of research and tie some part of your persona to that research!  Try to be specific and write the background so it emphasizes the concept of empathy.

Business Value

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

  1. Lecture: Good and Bad Metrics
    Describe ROI, TTM and CSat as all-around good metrics.  Explain red-yellow-green project dashboard and lines-of-code as bad metrics.  Ask for other examples of good or bad metrics.
  2. Handout: Value Metrics [PDF]
  3. Exercise: Value Metrics
    10 minutes.  At table teams try to come up with at least 10 quantitative and 10 qualitative metrics.  Use the handout as a worksheet.  Focus on metrics relevant to the simulation product, but also consider metrics that might be from other businesses or viewpoints (e.g. finance metrics, marketing analytics, etc.).
  4. Discussion: Value Metrics
    Throughout the classroom, share all the metrics and write them on a flip chart so they can all be seen at once.  Ask for insights or questions about metrics.
  5. Exercise: Key Metrics
    From the flipchart, each table team should choose 3 to 6 metrics that are most important to measure business success of their product.  It’s okay for that short list to include ROI, TTM and CSat.  Keep this list handy for the next part of the simulation.
  6. Discussion: Metrics and Product Vision
    Discuss if/how Product Vision helped to choose the key metrics.  If needed, allow a few moments for participants to reconsider the metrics they chose in light of their Product Vision.

Product Backlog Items

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

  1. Handout: Creating Product Backlog Items Worksheet [PDF]
  2. Exercise: Create Product Backlog Items
    Use the product box, the user categories, and the business metrics.  For each row in the worksheet, identify a feature, decide which user interacts with the product to exercise that feature, and choose the business metric that is most improved by implementing the feature.  For each, decide if the feature is visible to the user through the user interface.  The resulting worksheet should be filled up such that at least ten of the features are visible in the user interface.
  3. Handout: User Stories [PDF]
  4. Lecture: Writing Effective User Stories
    Use the example “As a Job Seeker, I can upload my resume, so that I get a job.”  Explain the user story template based on the handout.  Emphasize the idea of end user functionality.  Explain user stories as an important tool, but optional part of Scrum. Usually some time is spent on a discussion about physical note cards vs. electronic tools – emphasize the fact that the note cards support the values and principles of the Agile Manifesto while electronic tools (typically) subvert them.
  5. Exercise: Create User Stories
    Goal: 20 user stories for each group’s product, at least five user stories for the persona, and two user stories for each other type of user, all done in 20 minutes.  User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card.  The groups start by writing one or two User Stories together, then divide and conquer to create the rest.  At the end of the 20 minutes, there is a brief amount of time allocated to making sure there are no duplicated “features” described.
  6. Discussion: Review User Stories
    Workshop examples from each group.  Ensure that the “benefit” section of each story does not contain a feature.  Possibly discuss the three parts of a User Story as “who”, “what” and “why”.  The benefit is usually related to time, money or happiness and connects the User Story to the product vision.
  7. Handout: Simple Story Sizing [PDF]
  8. Exercise: Small, Uncertain, Large Effort Estimation
    Small means “easily and with certainty fits within a single Sprint”, large means “definitely requires more than a full Sprint of work”, and uncertain means either “uncertain size” or “uncertain if it will fit in a single Sprint”.  Teams create buckets and sort all the user stories into the three buckets – they must role play being technical contributors (Development Team Members).  Start by identifying one “small” one and one “large” one, then by dividing an conquering.  Final step is to verify that the small ones really are small.
  9. Handout: User Story Splitting [PDF]
  10. Lecture: Splitting User Stories
    Go through each of the “top” six splitting methods.  Provide simple examples where the group needs help.  E.g. error conditions as an example of splitting by business logic.
  11. Exercise: Split Some
    Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes.  Focus on splitting the items that were estimated in the “Large” or “Uncertain” buckets.
  12. Discussion: Review Splitting

Estimation and Financial Modelling

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

  1. Lecture: Effort, Value and ROI
    Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort.  Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
  2. Handout: The Bucket System [link to page with PDF download]
  3. Lecture: The Bucket System
    Review process based on handout.
  4. Exercise: Estimating Business Value
    10 minutes.  Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
  5. Discussion: Debrief the Bucket System
  6. Handout: The Planning Game [link to a page with PDF download]
  7. Lecture: The Planning Game
  8. Exercise: Estimating Effort
    20 minutes. Goal: estimate 3 user stories using the Planning Game.  Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
  9. Discussion: Debrief the Planning Game
  10. Handout: Methods of Ordering the Product Backlog [PDF]
  11. Lecture: Ordering a Product Backlog
    Review ROI as a method to order the PBIs.  Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
  12. Exercise: Calculating ROI and Ordering
    5 minutes.  Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
  13. Lecture: Simulation Wrap-Up – Where Does This Fit?
    Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.

NOTE: Permission to use the Product Owner Simulation exercise and print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
How-To Apply Agile, Reference Information

User Stories and Story Splitting

2 Comments

In Scrum and other Agile methods, a common way to manage feature requests is with User Stories.  I’ve been teaching people about User Stories and doing workshops with teams for a long time.  Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy.  Please feel free to download it and share it.  This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.

There are a number of sites out there that include some details that are left out of the reference.  Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence.  See also the great foundational article on “INVEST in Good Stories” by Bill Wake.

The format of a user story provided in the attachment was developed in conduction with Michael Hamman and Kara Silva and a number of other Agile coaches at Capital One in the 2004-2005 time frame.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Reference Information

The Planning Game – An Estimation Method for Agile Teams

8 Comments

The Planning Game [PDF] – printable reference.

Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)

Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards:

Planning Game Cards

(Please feel free to contact us if you would like some sets of Planning Game cards.  We will normally ship them to you at no cost!)

The Planning Game Process

  1. The team goes through all the items and chooses the one which has the lowest effort. Write the number “2” on this card (usually in the bottom right corner).
  2. The team looks at the item with the highest value.
  3. Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20” card. It is not permissible to select two cards.
  4. Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
  5. If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
  6. The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
  7. For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
  8. Once explanations are complete, the team members collect their cards and go back to step three.

Notes:
– it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
– in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
– in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
– voting should not include extensive discussion
– if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
– the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
– later on, items may take just one or two rounds of voting to arrive at a unanimous decision
– some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes

The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.

The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.

Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.

NOTE: The Planning Game is described as Planning Poker on wikipedia.  The version described there has some minor variations from this version.

A closely related method of Agile Estimation is the Bucket System.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info, Reference Information, Scrum, XP and Lean

Good Explanation of INVEST for User Stories

Leave a comment

Mike Caspar, a fellow agile coach,  just forwarded me this YouTube video to Bill Wake talking about INVEST for User Stories.  I worked briefly with Bill back in 2004/2005 at Capital One where he did some excellent coaching.  I strongly recommend checking out the video!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details