User story mapping jeff patton pdf download

Kano explains three general classifications for product features: must-haves, one-dimensionals, and delighters. Must-haves The products must have this features for me to be consider the product acceptable. One-dimensionals This car has many flaws. Buy it anyway. Separate objective quality from subjective quality Objective quality refers to the visible measurable, and easily validated characteristics of the product usually in relation to the products specifications.

Does the product perform bug free as specified? Expect objective quality to be high. Subjective quality refers to the specification or product design choices you make as a product owner. These choices affect the product users perception of quality Is the product simple to use? Is the product efficient to use? Do I like using the product? One persons delighter may leave others apathetic. Anothers must have is useless to other customers Jeff Patton, all rights reserved, www. Lets look at what happens if we take a naive incremental aproach to construction Lets start with the basic features of our bus.

Product goal: in 4 sprints be driving the coolest bus in town Jeff Patton, all rights reserved, www. We can leverage iteration to build up quality Iterating affords building up quality over time. Consider these four story splitting heuristics that build up quality Bare Necessity For the feature to be minimally demonstrable but not releasable, what is the minimal functionality Example: A form with only necessary fields and no validation.

Adding in sub tasks that are optionally performed? Safety What would make this feature safer for me to use? For both the user, and for the business paying for the software? What would make this feature easier to use? Building up quality iteratively and incrementally ships the best product possibleknow each story can be split into at least four parts We sprint 4 3 2 1 Early iterations strive to build bare necessities, later iterations build up quality Evaluating readiness based on subjective quality to understand doneness.

Product goal: in 4 sprints be driving the highest quality bus possible Jeff Patton, all rights reserved, www. This product growing strategy slowly brings the product into focus An artist envisions an entire painting by starting with a sketch or an under-painting and slowly building up detail Apply the same strategy to learn about the product domain as quickly as possible to chase out uncertainty before too heavily investing Opening Game Build up necessities Mid-Game Build out flexibility and business rule enforcement End-Game Refine the UI and interactions, take advantage of iterative learning.

Looking at the release of business value over time lets us see whats going on here cumulative business value. We need to be sure were building the right product. Mid Game Once were confident we have the shape of the product right, we begin to pile in value. Split a task-centric backlog item into smaller iteration stories using the 4 quality heuristics Work in small groups of people.

Review the Story Map the organized backlog for the Barneys problem Choose a story youd like to work with, one where your group can imagine a prospective user interface. Brainstorm the smaller stories that could build up the larger story to its full quality. Arrange your brainstormed stories into 3 pile: Jeff Patton, all rights reserved, www. Guidelines for releasing on time Thin stories aggressively during early sprints to build all essential functionality early.

Build up functionality only after all necessities are in place. Protect time in the final sprints for product refinement. Assess release readiness at the end of each sprint as part of product review. Open navigation menu. Close suggestions Search Search.

User Settings. Skip carousel. Carousel Previous. Carousel Next. What is Scribd? Patton User Story Mapping. Uploaded by Maximov Dmitry. Did you find this document useful? Is this content inappropriate? Report this Document. Flag for inappropriate content. Download now. Related titles.

Carousel Previous Carousel Next. Jump to Page. Search inside document. What causes you trouble with user stories Jeff Patton, all rights reserved, www. PM tester developer What are the details of what I need to work on today? How big is the story we want to talk about? Think of three levels: goal, task, and tool goal task tool Jeff Patton, all rights reserved, www. Ill perform several functional tasks in the context of an activity Functional or Sea level Id reasonably expect to complete this in a single sitting Think about user experience at this level Sub-Functional or Fish level Small tasks that by themselves dont mean much.

Try to talk about users tasks without talking about the kiosk tool this can be difficult 5 minutes Jeff Patton, all rights reserved, www. Business goals or pain points? Think about: Typical use, including typical problems Interesting plot points Goals and pains of your user The other ask questions to better understand After 5 minutes of discussion write out the scenario Pair one think about Carol: casual browser I want to find something good from a band I heard on the radio.

Technical User Stories are often forgotten during backlog maintenance or grooming activity. The Product Owner and the team more easily gravitate toward the functionality and defer the technical infrastructure to later. This happens for new applications defining base architecture and design and ongoing maintenance efforts extending architecture and refactoring alike. One of the best ways to expose technical stories is to perform a Story Brainstorming Workshop as defined by Mike Cohn.

I would also include end-to-end Release Planning as another effective tactic. When you take an end-to-end or holistic view to the work to deliver the entire project, then the technical stories often emerge with the discussions. You can read more about Release Planning and User Story Brainstorming Workshops in the references at the end of the article.

Very often your acceptance criteria or tests give you hints about technical stories. For example, the acceptance criteria above:. Give a solid hint about decomposing them out of the base story and perhaps creating another Technical User Story that would be focused towards a sub-service related to handing 2-phase questions. I could easily see doing this, particularly if the estimates on the base story are relatively large.

Of course it would create a dependency between the base authentication story and this one, but that might be worthwhile from an implementation and testing perspective. Mostly because it gets your team thinking at different levels about all of the needs they might have to properly implement within the application.

Joe Little talks a lot about this in his Release Planning writing—how release planning is really an effort to get the team and the organization to move from the tactical sprint-level to strategic release-level planning.

This then drives up rework, unmet dependencies, confusion, and worst of all, disappointed stakeholders when their expectations are unmet. While functional strategy is important, meaning how will we integrate and demonstrate customer facing stories and features.

I find that technical strategy is even more important. Er programmiert seit und arbeitet seit als Projektmanager. Aktuell ist er Vice President der Firma Fastk.

Mit ihrer Hilfe haben verschiedene internationale Unternehmen radikale Innovationen entwickelt und kommerzialisiert. Scrum dient dem agilen Management innovativer Produktentwicklung mit selbstorganisierten Teams. Dabei unterscheiden sie zwischen den produktbezogenen Aspekten, den entwicklungsbezogenen Aspekten und dem kontinuierlichen Verbesserungsprozess.

Quelle: buch. Mit diesem Leitfaden setzen Sie das Tool gewinnbringend ein, ohne es zuvor wochenlang studiert zu haben. Given story map organized vertically by necessity, we need only slice to plan time necessary less optional.

Choose coherent groups of features that consider the span of business functionality and user activities Support all necessary activities with the first release Improve activity support and add additional activities with subsequent releases Jeff Patton, all rights reserved, www.

Identify and prioritize desired outcomes before prioritizing the backlog Product goals describe what outcome or benefit received by the organization after the product is in use. Product goals suggest how the business will earn value from the product, and how we can tell were getting it Software built for internal use usually saves money or helps improve service to customers indirectly earning money Software built for use by customers earns money through direct sales, improved customer retention, or improved customer loyalty Product goals are specific to that product - not generic to any product.

A goal to earn more money isnt useful Given a product goal, ask: if were making progress towards this goal, how would we know it? What would we observe in our organization that indicates success? The answer to these questions are useful metrics Jeff Patton, all rights reserved, www.

Use product goals to identify candidate incremental releases, where each release delivers benefit Create horizontal swim-lanes to group features into releases Arrange features vertically by necessity from the users perspective Split tasks into parts that can be deferred till later releases. Use the product goals from your handouts to identify slices that incrementally realize product goals.

A product release roadmap targets benefit delivered over time A roadmap serves to clearly communicate release level product goals and benefits to stakeholders For each incremental release: Give the release a name or simple statement describing its purpose think mantra Write a short sentence or two describing what value or benefit the business gets Write a short sentence or two describing what value or benefit the users get.

EasyPOS Point of Sale Software Release 1: Replace the cash register Business: gets rid of old manual cash registers and gets accurate up to the minute sales information across locations. Users: Cashiers get an easier to use cash register that helps them make less mistakes, corrects them when they do, and saves time balancing cash drawers every night.

Iteratively and incrementally construct software Jeff Patton, all rights reserved, www. Traditional software development fixes scope then estimates, and attempts to fix time and cost Scope. Agile development fixes time and cost, then leverages iteration and incrementing to maximize scope Cost resources Agile software development. Leverage a shared understanding of desired product goals to minimize scope while maximizing value Cost resources Agile software development.

To release benefit on a schedule well need to leverage incremental and iterative thinking Whats the difference? And, doing it on time requires dead accurate estimation. Products with similar features often vary substantially in the price we pay Think about the high-level features in a car - well a bus in our example At a high level, all features are necessary But we know that all buses dont have the same price Each essential feature varies in subjective quality affecting the final price low cost Jeff Patton, all rights reserved, www.

Kano cautions us to consider quality as being composed of objective and subjective elements Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objectivesubjective split is the idea that objective quality pertains to the conformance to requirements while subjective quality pertains to the satisfaction of users.

Kano explains three general classifications for product features: must-haves, one-dimensionals, and delighters. Must-haves The products must have this features for me to be consider the product acceptable. One-dimensionals This car has many flaws. Buy it anyway. Separate objective quality from subjective quality Objective quality refers to the visible measurable, and easily validated characteristics of the product usually in relation to the products specifications.

Does the product perform bug free as specified? Expect objective quality to be high. Subjective quality refers to the specification or product design choices you make as a product owner. These choices affect the product users perception of quality Is the product simple to use? Is the product efficient to use? Do I like using the product? One persons delighter may leave others apathetic. Anothers must have is useless to other customers Jeff Patton, all rights reserved, www.

We can leverage iteration to build up quality Iterating affords building up quality over time. Each feature can be split into at least four parts Bare Necessity Capability, Flexibility Safety what is essential functionality necessary to demonstrate the simplest use of the feature? What would allow the feature to be used in alternative ways? These are characteristics that help prevent errors or validate data to prevent bad information from entering the system.

This includes adjustments to improve usability, visual and interaction design improvements to esthetic appeal, and improvements that help users do their work faster including architectural improvements or features such as short cuts or speed keys.