HalfDay Product Owner - Mike Cohn

2y ago
19 Views
2 Downloads
4.56 MB
46 Pages
Last View : Today
Last Download : 2m ago
Upload by : Aarya Seiber
Transcription

Becoming an EffectiveProduct OwnerMike Cohn14 November 20061Four questionsWhat are the primary responsibilities of theproduct owner?What are some differences between the roleof the product owner and the ScrumMaster?What skills should the ideal product ownerpossess?What things would you expect to happen ona project without a product owner? Mountain Goat Software, LLC2

Traditional view of product management Mountain Goat Software, LLC3Traditional development Prior to Scrum and Agile, it was consideredprudent to understand what was wanted andhow it was going to be delivered at the verystart of the project. All future work hung off, depended on thiswork. The theory was that changes at the start of theproject cost 1, but the same change madewhen the project was 60% complete cost 100. Mountain Goat Software, LLC4

Product owner helps reduce uncertaintyHighLowEnd UncertaintyEnd UncertaintyHighHighLowHighLowLowMeans UncertaintyMeans UncertaintyWaterfallAgile Mountain Goat Software, LLC5Emergence It is impossible to know all requirements inadvance“Thinking harder” and “thinking longer” canuncover some requirements, butEmergent requirements are those are users cannotidentify in advance Mountain Goat Software, LLC6

So what do we do? We talk more, write less But write some if you need to And all that this implies Show software to users Acknowledge that requirements emerge Progressively refine our understanding of theproduct And express this progressive refinement in the productbacklog Mountain Goat Software, LLC7The planning onion Mountain Goat Software, LLC8

Mountain Goat Software, LLC9Stories make great backlog itemsCard Stories are traditionally writtenon note cards. May be annotated with notes,estimates, etc.Conversation Details behind the story comeout during conversations withproduct ownerConfirmation Acceptance tests confirm thestory was coded correctlySource: XP Magazine 8/30/01, Ron Jeffries. Mountain Goat Software, LLC10

Samples from a travel website Mountain Goat Software, LLC11Where are the details? As a user, I can cancel a reservation. Does the user get a full or partial refund? Is the refund to her credit card or is it site credit?How far ahead must the reservation be cancelled? Is that the same for all hotels?For all site visitors? Can frequent travelers cancel later?Is a confirmation provided to the user? How? Mountain Goat Software, LLC12

Details as conditions of satisfaction The product owner’s conditions of satisfaction can beadded to a story These are essentially tests Mountain Goat Software, LLC13Details added in smaller stories Mountain Goat Software, LLC14

Stocking the product backlog You can start by identifying only a sprint’s worth ofbacklog items But, it’s often quick and easy to stock the productbacklog with most of its items This is helpful for release planning, expectation setting,and can influence design and codingThe key is to write product backlog items withdifferent levels of detail Fine-grained for stories about to be worked onCoarse-grained for stories further in the future Mountain Goat Software, LLC15The product backlog icebergUser StoryThemeA collection of relateduser stories.A description of desiredfunctionality told from theperspective of the user orcustomer.EpicA large user story. Mountain Goat Software, LLC16

An exampleImplementation-size stories;days to implementAn epic;weeks to implement Mountain Goat Software, LLC17An example Mountain Goat Software, LLC18

Story-writing workshops Includes developers, users, customer, others Brainstorm to generate stories Goal is to write as many stories as possible Some will be “implementation ready”Others will be “epics” No prioritization at this point Mountain Goat Software, LLC19Start with epics and iterate Mountain Goat Software, LLC20

Another approach Walk through a low-fidelity (paper) userinterface Ask open-ended, context-free questions as you go: What will the users most likely want to do next?What mistakes could the user make here?What could confuse the user at this point?What additional information could the user need?Consider these questions for each user role Mountain Goat Software, LLC21MyCookSpace.comYour team has been hired and given gobs of VC money tocreate a social networking site (like MySpace) for cooks. Theidea is that cooks will exchange recipes and tips. They’ll alsobuy kitchen-related products from the advertisers on thesite. We want some novel way of rewarding cooks who postthe best and most popular recipes as noted by other cookson the site.Write some user stories for MyCookSpace.com.Try this template:“As a user role , I want goal so that reason .” Mountain Goat Software, LLC22

How much detail?ProcessOutputJust-in-timejust-enoughInput Mountain Goat Software, LLC23What makes a good story? Mountain Goat Software, LLC24

ndependent Dependenices lead to problems estimating andprioritizing Can ideally select a story to work on without pullingin 18 other storiesegotiable Stories are not contracts Leave or imply some flexibilityaluable To users or customers, not developers Rewrite developer stories to reflect value to users orcustomers Mountain Goat Software, LLC25stimatable Because plans are based on user stories, we need tobe able to estimate themized Appropriately Small enough to complete in one sprint if you’reabout to work on it Bigger if further off on the horizonestable Testable so that you have a easy, binary way ofknowing whether a story is finished Done or not done; no “partially finished” or “doneexcept” Mountain Goat Software, LLC26

Mountain Goat Software, LLC27Prioritizing the product backlogThree steps1. Organize needs into themes2. Assess importance of each theme3. Prioritize themes Mountain Goat Software, LLC28

Why themes? Often individual stories cannot be prioritizedagainst each other What’s more important in a word processor? The A key or the E key?Tables or undo?What’s more important on a car? The left front wheel or the right front wheel?Increased leg room or a larger engine? Mountain Goat Software, LLC29Steps for organizing into themes1. Write each story on its own note card orpost-it2. Eliminate redundant stories3. Group similar stories4. Label each group with a theme name5. If you have a lot of themes or have smallthemes, consider making themes of themes6. Review the results Mountain Goat Software, LLC30

Affinity grouping Distribute cards equally to all participants No particular pattern to how you do this Someone reads a card and places in on wall /table Others look for similar cards and add them to it Next person reads a card, places it, and othersplace similar cards with it Continue repeating until out of cards Mountain Goat Software, LLC31An example Mountain Goat Software, LLC32

Typical results Mountain Goat Software, LLC33Step 2Assess importance of each theme Two general approaches1. Team opinion2. Survey users Some specific approaches Theme screeningTheme scoringRelative weightingKano analysisFinancial analysisAnalytic Hierarchy Process Mountain Goat Software, LLC34

Choosing your approach Mountain Goat Software, LLC35Theme screening Identify 5-9 (approximately) selection criteriafor what is important in the next release Select a baseline theme Likely to be included in the next releaseUnderstood by most team members Assess each candidate theme relative to thebaseline theme Mountain Goat Software, LLC36

Theme screening: an example -0- 0 -00000 000 0000 0 better than0 same as- worse than Mountain Goat Software, LLC37Theme scoring Like theme screening but selection criteria areweighted Need to select a baseline theme for each criteria Avoids compression of a categoryEach theme is assessed against the baseline for eachselection criteria Mountain Goat Software, LLC38

Theme scoring: An .6040.605052.5021.0031.50 Mountain Goat Software, LLC39Prioritizing MyCookSpace.com Assume we have a minimally functional site upwith 4,000 registered cooks We want 400,000 cooks What’s important to the company in making thisdecision?As groups, decide whether you want to use themescreening or theme scoring.Identify 4-5 themesIdentify some selection criteriaComplete a theme screening/scoring worksheet Mountain Goat Software, LLC40

Theme Screening WorksheetSelection CriteriaThemesNet scoreRankContinue? Better than0 Same as Worse than

Net Selection CriteriaWeightTheme Scoring WorksheetWeightedScore

Relative weighting Assess the impact of having a story/theme from 1-9Assess impact of NOT having it from 1-9Calculate the value of each story or theme relative to theentire product backlog This gives you the relative value of that story or themeDevelopers estimate the cost of each story themeCalculate the cost of each story or theme relative to theentire product backlog This gives the relative cost of that story or themePriority is given by (Relative Value Relative Cost) Mountain Goat Software, LLC41Relative weighting: an example8614406444919211314027 1151910294229 100 Mountain Goat Software, LLC42

An example with weights2186224164449220384027 14119112142299372 Mountain Goat Software, LLC43Priority poker An iterative approach to estimating: Stakeholders with a say in prioritizing are invitedEach is given a deck of cards with the values A-9A moderator reads a theme and it’s discussed brieflyEach estimator selects a card that is his or her estimate ofthe relative benefit of the themeCards are turned over so all can see themDiscuss differences (especially outliers)Re-estimate until estimates convergeRepeat for relative penalty Mountain Goat Software, LLC44

Priority poker - an exampleA237 8 964 5 Mountain Goat Software, LLC45Relative weighting MyCookSpace.com Using priority poker and the relative weightingworksheet provided, prioritize the themes you’vepreviously identified for MyCookSpace.com Mountain Goat Software, LLC46

Relative Weighting WorksheetTotal:100Total Value Relative Benefit Relative Penalty ( weights if used)Value Percent Total Value (Total Value)Cost Percent Estimate EstimatePriority Value Percent / Cost Percent (higher higher priority)100PriorityCost PercentEstimateValue PercentTotal ValueRelative PenaltyThemesRelative BenefitWeight:

Kano analysis Mountain Goat Software, LLC47Surveying users To assess whether a feature is baseline, linear,or exciting we can: Sometimes guessOr survey a small set of users (20-30) A functional question We ask two questions How do you feel if a feature is present?And a dysfunctional question How do you feel if that feature is absent? Mountain Goat Software, LLC48

Functional and dysfunctional forms Mountain Goat Software, LLC49Categorizing an answer eIndifferent Mountain Goat Software, LLC50

Aggregating resultsTheme Mountain Goat Software, LLC51What to include All of the baseline features By definition, these must be present Some amount of linear features But leaving room for at least a few exciters Mountain Goat Software, LLC52

Upcoming public classes Mountain Goat Software, LLC53Mike Cohn contact info Mountain Goat Software, LLC54

Chapter 2Writing StoriesIn this chapter we turn our attention to writing the stories. To create good stories we focus on six attributes. A good story is: Independent Negotiable Valuable to users or customers Estimatable Small TestableBill Wake, author of Extreme Programming Explored and RefactoringWorkbook, has suggested the acronym INVEST for these six attributes (Wake2003a).IndependentAs much as possible, care should be taken to avoid introducing dependenciesbetween stories. Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high prioritya story that is dependent on a story that is low priority. Dependencies betweenstories can also make estimation much harder than it needs to be. For example,suppose we are working on the BigMoneyJobs website and need to write storiesfor how companies can pay for the job openings they post to our site. We couldwrite these stories:1. A company can pay for a job posting with a Visa card.2. A company can pay for a job posting with a MasterCard.17From "User Stories Applied" by Mike CohnCopyright 2004, Addison-Wesley

18WRITING S TORIES3. A company can pay for a job posting with an American Express card.Suppose the developers estimate that it will take three days to support thefirst credit card type (regardless of which it is) and then one day each for thesecond and third. With highly dependent stories such as these you don’t knowwhat estimate to give each story—which story should be given the three dayestimate?When presented with this type of dependency, there are two ways around it: Combine the dependent stories into one larger but independent story Find a different way of splitting the storiesCombining the stories about the different credit card types into a single largestory (“A company can pay for a job posting with a credit card”) works well inthis case because the combined story is only five days long. If the combinedstory is much longer than that, a better approach is usually to find a differentdimension along which to split the stories. If the estimates for these stories hadbeen longer, then an alternative split would be:1. A customer can pay with one type of credit card.2. A customer can pay with two additional types of credit cards.If you don’t want to combine the stories and can’t find a good way to splitthem, you can always take the simple approach of putting two estimates on thecard: one estimate if the story is done before the other story, a lower estimate ifit is done after.NegotiableStories are negotiable. They are not written contracts or requirements that thesoftware must implement. Story cards are short descriptions of functionality,the details of which are to be negotiated in a conversation between the customer and the development team. Because story cards are reminders to have aconversation rather than fully detailed requirements themselves, they do notneed to include all relevant details. However, if at the time the story is writtensome important details are known, they should be included as annotations tothe story card, as shown in Story Card 2.1. The challenge comes in learning toinclude just enough detail.Story Card 2.1 works well because it provides the right amount of information to the developer and customer who will talk about the story. When a devel-From "User Stories Applied" by Mike CohnCopyright 2004, Addison-Wesley

N EGOTIABLEA company can pay for a job posting with a credit card.Note: Accept Visa, MasterCard, and American Express.Consider Discover. Story Card 2.1 A story card with notes providing additional detail.oper starts to code this story, she will be reminded that a decision has alreadybeen made to accept the three main cards and she can ask the customer if adecision has been made about accepting Discover cards. The notes on the cardhelp a developer and the customer to resume a conversation where it left offpreviously. Ideally, the conversation can be resumed this easily regardless ofwhether it is the same developer and customer who resume the conversation.Use this as a guideline when adding detail to stories.On the other hand, consider a story that is annotated with too many notes,as shown in Story Card 2.2. This story has too much detail (“Collect the expiration month and date of the card”) and also combines what should probablybe a separate story (“The system can store a card number for future use”).A company can pay for a job posting with a credit card.Note: Accept Visa, MasterCard, and American Express.Consider Discover. On purchases over 100, ask for card IDnumber from back of card. The system can tell what type of cardit is from the first two digits of the card number. The systemcan store a card number for future use. Collect the expirationmonth and date of the card. Story Card 2.2 A story card with too much detail.Working with stories like Story Card 2.2 is very difficult. Most readers ofthis type of story will mistakenly associate the extra detail with extra precision.However, in many cases specifying details too soon just creates more work. Forexample, if two developers discuss and estimate a story that says simply “acompany can pay for a job posting with a credit card” they will not forget thattheir discussion is somewhat abstract. There are too many missing details forFrom "User Stories Applied" by Mike CohnCopyright 2004, Addison-Wesley19

20WRITING S TORIESthem to mistakenly view their discussion as definitive or their estimate as accurate. However, when as much detail is added as in Story Card 2.2, discussionsabout the story are much more likely to feel concrete and real. This can lead tothe mistaken belief that the story cards reflect all the details and that there’s nofurther need to discuss the story with the customer.If we think about the story card as a reminder for the developer and customer to have a conversation, then it is useful to think of the story card as containing: a phrase or two that act as reminders to hold the conversation notes about issues to be resolved during the conversationDetails that have already been determined through conversations becometests. Tests can be noted on the back of the story card if using note cards or inwhatever electronic system is being used. Story Card 2.3 and Story Card 2.4show how the excess detail of Story Card 2.2 can be turned into tests, leavingjust notes for the conversation as part of the front of the story card. In this way,the front of a story card contains the story and notes about open questionswhile the back of the card contains details about the story in the form of teststhat will prove whether or not it works as expected.A company can pay for a job posting with a credit card.Note: Will we accept Discover cards?Note for UI: Don’t have a field for card type (it can be derivedfrom first two digits on the card). Story Card 2.3 The revised front of a story card with only the story and questionsto be discussed.Valuable to Purchasers or UsersIt is tempting to say something along the lines of “Each story must be valued bythe users.” But that would be wrong. Many projects include stories that are notvalued by users. Keeping in mind the distinction between user (someone whouses the software) and purchaser (someone who purchases the software), suppose a development team is building software that will be deployed across aFrom "User Stories Applied" by Mike CohnCopyright 2004, Addison-Wesley

VALUABLETOP URCHASERSORU SERSTest with Visa, MasterCard and American Express (pass).Test with Diner’s Club (fail).Test with good, bad and missing card ID numbers.Test with expired cards.Test with over 100 and under 100. Story Card 2.4 Details that imply test cases are separated from the story itself.Here they are shown on the back of the story card.large user base, perhaps 5,000 computers in a single company. The purchaser ofa product like that may be very concerned that each of the 5,000 computers isusing the same configuration for the software. This may lead to a story like “Allconfiguration information is read from a central location.” Users don’t carewhere configuration information is stored but purchasers might.Similarly, stories like the following might be valued by purchasers contemplating buying the product but would not be valued by actual users: Throughout the development process, the development team will producedocumentation suitable for an ISO 9001 audit. The development team will produce the software

of the product owner and the ScrumMaster? What are the primary responsibilities of the product owner? What skills should the ideal product owner possess? What things would you expect to happen on a proj

Related Documents:

Planning and Tracking Agile Projects Mike Cohn - background Mounta

– Mike Cohn, Mountain Goat Software www.mountaingoatsoftware.com – Scrum and The Enterprise by Ken Schwaber – Succeeding with Agile by Mike Cohn – Agile Software Development Ecosystems by Jim Highsmith – Agile Software Development with Scrum by K. Schwaberand M. Beedle – User Stories Applied fo

Product Owner / Product Owner relationship. In this structure, the Product Owner makes all the decisions, but off-line vets those decisions with the Lead Product Owner. This situation keeps the Lead Product Owner “in-charge

Dyer Well Drilling and Service, Inc. - Mike Dyer Mike Katz Well Drilling - Mike Katz Mike LaLone Well Drilling - Mike LaLone Maurer & Parks Well Drilling, Inc. - Jack and Scott Peru Mid State Oil Tools - Craig Machuta Lee Rich Well Drilling - Lee Rich Terry’s Well Service, Inc. - Terry Cords

Product Manager or Chief Product Owner Product Owner Strategic product decisions Product strategy, product roadmap, stakeholder management, financial forecast Tactical product decisions Product backlog management, epics and user

Agile Planning: Mike Cohn's Planning Onion Strategy -defines the vision associated with a business need or direction. Portfolio -defines the overall product offering that consists of applications and tools and how they integrate. Product -defines a product vision and outlines the road-map for the product. Release -represents a prioritized

Project Report and Technical Documentation Thomas Jund info@jund.ch Andrew Mustun andrew@mustun.com Laurent Cohn info@cohn.ch 24th May 2004 Version 1.0. ii Abstract In this paper we present quaneko, a tool to e ciently nd data on the local computer system. The purpose of this document is the technical specication and description of the

3 For referenced ASTM standards, visit the ASTM website, www.astm.org, or contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM Standards volume information, refer to the standard’s Document Summary page on the ASTM website. 4 Withdrawn. 5 Available fromAmerican Concrete Institute (ACI), P.O. Box 9094, Farmington