Tag Archives: PBI

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

Learn more about transforming people, process and culture with the Real Agility Program

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Product Backlog Refinement

Learn more about transforming people, process and culture with the Real Agility Program

The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.

On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.

The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint.  This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.

Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.

The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP).  The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution).  Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team.  They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail.  Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big.  Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.

The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog

But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.

It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Full-Day Product Owner Simulation Exercise

Learn more about transforming people, process and culture with the Real Agility Program

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Any stakeholder (e.g. Team Member, salesperson, client) can suggest a new PBI

Learn more about transforming people, process and culture with the Real Agility Program

The Product Backlog is a list of potential work to be done for future Sprints.  This list is most vibrant when as many people as possible contribute to it.  Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value.  Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome.  Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision).  If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost.  Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Known defects (external quality) generally are ordered at the top of the Product Backlog to be fixed in the next Sprint

Learn more about transforming people, process and culture with the Real Agility Program

One of the key benefits of the using Scrum is that it allows the team to quickly identify defects and obstacles.  Now that the team has made these known, the team has the ability to remove and fix these defects.  What is the value of identifying problems in the product when nothing is done to repair them?  The team will become much faster if it can improve the quality on its own by removing known defects and making the software better.  Then the team will be able to take on more audacious goals instead of being weighed down by quality problems.  Moving known defects to the top of the Product Backlog places quality work as a central goal for the team to achieve which directly improves the product, makes customers and users of the software much happier and invigorates the team to continue to become more effective.  Placing known defects away from the top of the Product Backlog causes morale challenges, acceptance by the team of poor quality work and creates an atmosphere of apathy.  These are likely to cause a failure by the Scrum Team to deliver on its goals.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: PBIs are invitations to conversations, not detailed specifications

Learn more about transforming people, process and culture with the Real Agility Program

Product Backlog Items are brief descriptions of a feature or function.  Usually they are short enough that they could be hand-written on a small note card.  This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations.  The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides.  Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it.  Part of the conversation is the actual work being done during a Sprint.  Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs.  If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution.  The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities.  If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code.  PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: PBIs are written as User Stories (“As a ___ I can ___ so that ___”)

Learn more about transforming people, process and culture with the Real Agility Program

The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum.  The User Story format is an effective way of communicating end user value to the Scrum Team.  The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system).  A User Story is made up of three “C’s”: Card, Conversation and Confirmation.  The Card is the written version of the story (usually a physical card on the wall).  It is considered to be an “invitation to a conversation”.  The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card.  Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story.  A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them.  Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this.  This is just enough information to make sure that an effective conversation occurs.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: PBIs have their effort estimated collectively by the team who will be implementing them

Learn more about transforming people, process and culture with the Real Agility Program

The Product Owner brings Product Backlog Items to the Scrum Team to estimate their effort (cost).  In order to create the right environment of safety and accountability, no Product Backlog Item is estimated by a single member of the Scrum Team, or even a subset of the team membership.  By having all the members of the Scrum Team participate in the estimation work for every Product Backlog item, it becomes impossible to blame a single Team Member for a poor estimate.  At a practical level, it is should be very rare that a single Product Backlog Item is fully implemented by a single Team Member.  Therefore, estimates should consider the collective effort of the Scrum Team, and this can only be determined by having all the Team Members participate in the estimation work.  If the team delegates estimation to a single person, or if one person dominates the estimation work, the other Team Members will not have ownership of the estimates and will be able to deny accountability.  The pressure on the team from collective estimation encourages teamwork, cross-training and these behaviours in turn promote the development of a high-performance team.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail