Stories, Backlog & Mapping

About Dimitri Ponomareff Agile Coach & Trainer ● Wolters Kluwer (Data-warehouse) ● Apriva (Mobile) ● Choice Hotels International (Web) ● First Things First / AZ ECDH (Data-warehouse) ● JDA Software Group (Software) ● Insight Enterprises (Web) Facilitator of “The 7 Habits of Highly Effective People” Project Manager ● Project Management Professional (PMP) ● Agile Certified Practitioner (PMI-ACP) ● Certified ScrumMaster (CSM) ● Certified Scrum Practitioner (CSP) IT Professional ● Vice President of Communications - PMI Phoenix Chapter ● Director of Web Technologies - I-ology ● E-Commerce Manager - Insight Canada

Agile Stories ● Why, What & How ● Work breakdown structure (WBS) ● What is a story? ○ Story form ○ Cards - Conversation - Confirmation ● Story writing workshops ○ Epics and story breakdown ○ INVEST guideline ● Stories vs. Use Cases vs. Requirements ● Product Backlog of stories ● Personas

Why, What & How● WHY are we doing this? Voice of the stakeholder (Stakeholders)● WHAT needs to be done? Voice of the user (Product Owner, Subject Matter Expert)● HOW do we build it? Voice of the developer (Scrum Team)

Alternative to Work Breakdown Structure (WBS) WBS or traditional projects Activity Analysis Design Coding Testing Functionality Feature Feature Feature Module Module Module Feature Breakdown Structure Functionality Story Story Story Story Activity Analysis Design Coding Testing Define the project plan in terms of what will be delivered rather than what work steps will be performed.

What is a User Story? ● User Stories provide a light-weight approach to managing requirements for a system. ● A short statement of function captured on an index card and/or in a tool. ● The details are figured out in future conversations between the team and the product owner or customers. ● This approach facilitates just in time requirements gathering, analysis and design by the following activities: ○ Slicing user stories down in release planning ○ Tasking user stories out in sprint planning ○ Specifying acceptance test criteria for user stories early in development

Story Form As a < role > I can < activity > so that < business value > ● Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity. ● Activity – represents the action to be performed by the system. ● Business Value – represents the value to the business. Why is this story important?

Acceptance Criteria ● like stories its written in simple language ● define the conditions of success/satisfaction ● provide clear story boundaries ● remove ambiguity by forcing the team to think through how a feature or piece of functionality will work from the user’s perspective ● checklist or template of things to consider for each story ○ list of impacted modules and/or documents ○ specific user tasks, business process or functions ● establish the basis for acceptance testing ○ steps to test the story (given-when-then scenarios) ○ type of testing (manual vs. automated)

The 3 Cs As a user, I can login and gain access to the intranet, so that I 1. Card can collaborate with all the Written on a card organization. 2. Conversation What about Details captured in conversations expired accounts? Can it remember my login? 3. Confirmation Acceptance criteria confirm that the story 1.Expired accounts fail is Done. 2. Remember the login, not the Source: XP Magazine 8/30/01, Ron Jeffries password 3. After 3 attempts the account is locked out for 24h (SOX compliance)

Story writing workshops ● define clear roles: facilitator and story writer ● include the entire team and anyone who can express the WHAT aligned to the WHY (subject matter experts, users, customers, etc...) ○ all participants must stay away from the HOW ○ promote open discussion and use open ended questions ● consider using story-boarding technique ○ work around themes/features ○ begin with the end in mind ● write as many stories as possible, plan for 2-4 hours ○ no need for prioritization ○ high level acceptance criteria

Product, Epics & Stories Product Epics Stor Stor Stor Stor Stor Stor Stor Stor Stor y y y y y y y y y Stories Stor Stor Stor Stor Stor Stor Stor Stor Stor y y y y y y y y y

Start with Epics and break down into Stories As a frequent flyer, I want to book a room using miles As a frequent flyer, I want to check my account. As a frequent flyer, I want to rebook a room I take often As a frequent flyer, Frequent flyer I want to book a room. As a frequent flyer, I want to request an upgrade As a frequent flyer, I want to … As a frequent flyer, I want to check if my upgrade cleared.

INVEST guideline from Bill WakeI - IndependentThe user story should be self contained, in a way that there is no inherent dependency on another user story.N - NegotiableUser stories, up until they are part of a Sprint, can always be changed and rewritten.V - ValuableA user story must deliver value to the end user.E - EstimableYou must always be able to estimate the size of a user story.S - Sized appropriatelyUser stories should not be so big as to become impossible to plan/task/prioritize with a certain level ofcertainty.T - TestableThe user story or its related description must provide the necessary information to make test developmentpossible.

Stories vs. Use Cases vs. Requirements Stories Use Cases Requirements Goal generate conversation capture a behavior establish a contract a process Scope a single activity everything "day in the life" Format a single sentence numbered bullets specifications open for negotiation and locked, changes may impact locked, require scope Completeness refinements entire process change and approvals Language simple, comprehensible structured, flows precise, technical

Personas● modeling techniques to describe your target audience ○ Behavior patterns ○ Goals ○ Skills ○ Attitudes ○ Motivation ○ Environment● useful when you don’t have easy access to real users● help to guide your decisions about functionality and design● be in your users shoes - think the way that your users would● ideal for building test script relying

Backlog Management ● Blitz Planning ● Product Road Map ● Story Mapping ○ The Walking Skeleton ○ Release Planning ● Wireframes

Blitz Planning Process/Mechanics ● everyone writes down all the tasks they know of onto index cards and throws them onto a long table ● everyone sorts, adds estimates and notes ● we look for the Walking Skeleton and the First Delivery ● we strategize and restrategize about roadblocks, costs, time, resources, moving the cards around as we go ● some people might see this as an annotated Pert chart, constructed collaboratively with cards Allow 90 minutes - 15 minutes for instructions, 40+ minutes for the assignment, 20 minutes to discuss, and 15 minutes for variations in the program. The key is to see the variations of the project plan grow under your eyes. Blitz Planning is also known as Project Planning Jam Session (as in jazz)

Product road map ● a roadmap is a planned future, laid out in broad strokes ○ proposed product releases, listing high level functionality or release themes, rough target dates ● intentions for the future given what we know and believe today - they are not commitments (disclaimer) ● should be formulated by first understanding the target users, the market, and the underlying technologies ● short development cycles and repeated prioritization of functionality in the product backlog clashes with a long term product map - making a long range roadmap has always been a real challenge in general ● forms an integral part of any product strategy and provide the framework for plan changes and the impact they would have on the product ● a good product roadmap should invariably deliver the right products with the right features at the right time to the right customers

Product road map example...

Product Backlog of stories ● a list of all desired work on the project “The requirements” ● owned, managed and prioritized by the Product Owner ● items estimated by the team ● re-prioritized at the start of each iteration ● ideally expressed such that each item has value to the users or customers of the product

Story Mapping Problem ● You have a backlog full of stories. ● You have a set of prioritized features that need to go out with your next release. ● You are in need of a simple and quick way of viewing dependencies between stories and mapping features and tasks to their corresponding stories. What do story maps do? ● Group related stories together ● Break down stories from a user point of view ● Make visible the workflow or value chain ● Provide a useful context for prioritization ● Help confirm the completeness of your backlog ● Plan releases in complete and valuable slices of functionality

Story MappingHow do you do story mapping? ● Chose user roles for the product ● Figure out what each user does within the product ● Map those user-roles to User Activity, User Task, and User Sub-Task (Color coordination helps) ● Cluster items that seem similar and create labels for the clusters ● Arrange activities in a swim-lane to visualize workflow ● Meet with stakeholders and spot check the workflow ● On review, make changes ● Identify goals of the release with user-specific stories in mind

Story Mapping activity activity activity task task task task task task task task details details details details details details ● helps us focus on the big picture and why we are building the product (business value instead of feature details) ● look at product backlog differently ● keep breaking things down as you go down a path of functionality ● organize the backlog into a logical units for development ● elicit the core functionality of a product from a user-centric point of view ● focus on what the customers or users must do in order for the product to be useful (bells and whistles can come later)

The Walking Skeleton The Walking Skeleton is a tiny implementation of the of the system that performs a small end-to-end function.Plan usingyour backbone! It is missing the flesh of the application functionality. The Backbone time The Walking Skeleton necessity

Story Mapping & Release Planning time necessity time Release #1 - Walking Skeleton necessity Release #2 Release #3 Release #4

Wireframes ● Remember: the most effective/rich level of communication is 2 people in front of a white board ○ helps the team to communicate better internally and externally ● wireframe capture something in its simplest form (bare bones) ○ flesh out something - based on the idea of adding flesh to a picture that shows only the bones of a creature Steps for using wireframes 1. we rapidly create wireframes from the basic description of a user story 2. we gather feedback and adjust the wireframes accordingly (no coding yet) 3. the user interface is designed based on the approved wireframe ● various tools can be used for creating wireframes, but keep it simple! ○ Visio, wiki, scanned drawing, etc...

Wireframes (example & pros/cons) PROS ● simple and fast visual format ● generate feedback ● minimize rework / uncover potential gaps ● reduces miscommunication ● illustrates dependencies ● easy review process ● great when associated with workflow diagramming ● uncover usability issues (early) CONS ● may limit the team creativity if they are over-engineered or stylized ● may create false promises about layout or system functionality ● not kept up to date with the story (acceptance criteria) ● should not be created too early ● who is responsible (ideally) to create/manage the wrieframes ● eventually reach a point of diminishing returns

PMI-ACP - Certification Training (3 days - 21 PDUs) March 28, 29 and 30, 2012 (Phoenix) May 23, 24 and 25, 2012 (Raleigh-Durham, NC) June 6, 7 and 8, 2012 (Phoenix) REAL-ILT Remote Education for Advanced Learning – Instructor Led Training Agile Exams will be included in your PMI-ACP Prep Workshop.

Agile Coaching, Staffing and Training. Learn more at www.torak.com

Thank You

Resources and References ● www.scrumalliance.org ● www.mountaingoatsoftware.com/scrum ● AgileProductDesign.com http://www.agileproductdesign.com/presentations/user_story_mapping/index.html ● Agile and Iterative Development: A Manager’s Guide by Craig Larman ● Agile Estimating and Planning by Mike Cohn ● Agile Project Management with Scrum by Ken Schwaber ● Agile Retrospectives by Esther Derby and Diana Larsen ● Agile Software Development Ecosystems by Jim Highsmith ● Agile Software Development with Scrum by Ken Schwaber and Mike Beedle ● Scrum and The Enterprise by Ken Schwaber ● User Stories Applied for Agile Software Development by Mike Cohn

This presentation was inspired by the work of many people and we have done our very best to attribute allauthors of texts and images, and recognize any copyrights. If you think that anything in this presentationshould be changed, added or removed, please contact us. http://creativecommons.org/licenses/by-nc-nd/3.0/

http://www.torak.com	58
http://torak.com	12

Stories, Backlog & Mapping

by Dimitri Ponomareff on Feb 15, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 70

Statistics

Stories, Backlog & Mapping — Presentation Transcript