Tactical Product Ownership day 1: product scope and planning Incremental Releases Users & Stakeholders Will Love Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com jpatton@acm.org Jeff Patton, jpatton@acm.org

The ground we’ve crossed so far: Incremental Releases Users & Stakeholders Will Love The ground we’ve crossed so far: Collaborative project inception Identifying strong business goals and using them to drive decisions about users and use. Envisioning solutions Using user scenarios, paper prototypes, and iterative evaluation to identify solutions Collaboration Working with people to elicit information, facilitate groups, and collaborate effectively. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Our goals for the next two days: Move from conceptual analysis and scope definition to detailed Agile project work Plan a project composed of multiple thinned releases Split larger planning grade stories into sprint level stories Develop acceptance criteria for those stories Properly exploit iteration in Agile development Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love candle dipping Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Starting with where we’ve been Jeff Patton, jpatton@acm.org

The software we choose to build fits in a “product shaped hole” Incremental Releases Users & Stakeholders Will Love The software we choose to build fits in a “product shaped hole” software organization (goals) problem context software users (goals) use (tasks) software software solution The quality of the product is a function of how well it fits inside it’s problem context. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

The software we choose to build fits in a “product shaped hole” Incremental Releases Users & Stakeholders Will Love The software we choose to build fits in a “product shaped hole” organization (goals) customer (value proposition) problem context users (goals) use (activities & tasks) software software solution The quality of the product is a function of how well it fits inside it’s problem context. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Goals, users and activities supported by software form a dependent hierarchy Business Goals (Increase Revenue, Reduce Costs) User Constituencies (The people that will use some solution to meet business goals) Activities & Tasks performed by users using software © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Prioritizing goals and eliminating low priority goals has cascading effects on project scope Business Goals (Increase Revenue, Reduce Costs) User Constituencies (The people that will use some solution to meet business goals) Activities & Tasks performed by users using software © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Prioritize your goals before you prioritize your user story backlog Incremental Releases Users & Stakeholders Will Love Prioritize your goals before you prioritize your user story backlog Business Goals (Increase Revenue, Reduce Costs) User Constituencies (The people that will use some solution to meet business goals) Activities & Tasks performed by users using software © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

We learned techniques to model each layer of the problem context Incremental Releases Users & Stakeholders Will Love We learned techniques to model each layer of the problem context Business Goals (Increase Revenue, Reduce Costs) User Constituencies (The people that will use some solution to meet business goals) Activities & Tasks performed by users using software © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

We learned techniques to model each layer of the problem context Incremental Releases Users & Stakeholders Will Love We learned techniques to model each layer of the problem context Identify goals that motivate creation of the product Use “why questions” to find goals that track back to increasing revenue or reducing cost Use the question “how would we know if we were making progress towards this goal” to identify metrics Identify types of users as roles relative to the business, a process, or the solution Identify characteristics of these groups relevant to the solution Build a persona leveraging those details Identify feature ideas and product design imperatives Identify large collections of related tasks as activities Identify tasks within those activities Record details of tasks Arrange activities and tasks into a typical workflow order © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love OVERVIEW OF EXTRANET EVENT PAGES Extranet Event Goals, Users and Activities Create transparency into community to enable roundtable participants to engage with each other effectively across and within communities of interest, geographic communities, and events. Lay the architectural foundation for McKinsey Connect Platform GOALS C- Level Participants C-Level Assistants Event Coordinator Event Planner Editor USER CONSTITUENTS “I want to network with colleagues that can help me with goals and problems I’m facing in my company” “My boss spends most of his time in meetings and traveling. It’s up to me to keep him informed.”” “I want to keep my community of CSOs active and engaged.” “There are lots of important details to take care of for a workshop to go smoothly.” “McKinsey’s reputation, and the quality of interaction we have with CSOs relies on relevant high quality content.” I want to: View upcoming events Respond to invitations View historic events Modify my profile Find knowledge Find peers Post content, pose questions Look for a job As a proxy I will: View upcoming events Respond to invitations I need to: Planning events Prepare for events Communicate event details Maintain event information Conduct event Manage post-event publishing Review historic events Maintain participant profiles I need to: Planning events Prepare for events Maintain event information Conduct events Manage post-event publishing Review historic events I need to: Maintain event information Manage post-event publishing Review historic events Maintain participant profiles Schedule content events Administrate surveys Manage content Manage community USER ACTIVITIES Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Solution inception alternates between analyzing the problem context and exploring possible solutions activity & task analysis (how do users achieve goals today?) user modeling user research user story writing problem analysis user interface design solution definition user scenario writing Incremental release planning business problems & goals analysis activity and task design (how might users better reach goals?) incremental release strategy idea time Often, design starts with a candidate solution in mind. Exploring the problem helps validate the solution. As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Solutions design alternates between analyzing the problem context and exploring possible solutions activity & task analysis (how do users achieve goals today?) user modeling user research user story writing problem analysis user interface design solution definition user scenario writing Incremental release planning business problems & goals analysis activity and task design (how might users better reach goals?) incremental release strategy idea time Often, design starts with a candidate solution in mind. Exploring the problem helps validate the solution. As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Solutions design alternates between analyzing the problem context and exploring possible solutions activity & task analysis (how do users achieve goals today?) user modeling user research user story writing problem analysis user interface design solution definition user scenario writing Incremental release planning business problems & goals analysis activity and task design (how might users better reach goals?) incremental release strategy idea time Often, design starts with a candidate solution in mind. Exploring the problem helps validate the solution. As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

How are these concept sitting today? Incremental Releases Users & Stakeholders Will Love How are these concept sitting today? Consider the hierarchy of: business goal  user types  usage as activities and tasks  software specification Is the hierarchy of concerns understandable in the project you’re working on? Have you been able to practice approaches to: elicitation facilitation collaboration © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Build up a “one-pager” for new KNOW features Incremental Releases Users & Stakeholders Will Love Build up a “one-pager” for new KNOW features Demonstration: Interviewing Zanub, capture information for a one-page overview of the current KNOW additions Practice In small groups, 1 or 2 interviewers, one interviewee, build quick “one-pagers” for existing McKinsey projects © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Incremental release planning, second dip Jeff Patton, jpatton@acm.org

The product owner plans the product in layers Incremental Releases Users & Stakeholders Will Love The product owner plans the product in layers © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

The product owner plans the product in layers Incremental Releases Users & Stakeholders Will Love The product owner plans the product in layers Product or Project What business objectives will the product fulfill? Product Charter Elevator Pitch Release How can we release value incrementally? What subset of business objectives will each release achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release plan Sprint What specifically will we build? (user stories) How will this sprint move us toward release objectives? Sprint Plan Story (Backlog Item) What user or stakeholder need will the story serve? How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love The Planning Onion can grow to include product portfolios and business strategy Product or Project What business objectives will the product fulfill? Product Charter Elevator Pitch Release How can we release value incrementally? What subset of business objectives will each release achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release plan Product or Project Release Sprint Story Sprint What specifically will we build? (user stories) How will this sprint move us toward release objectives? Sprint Plan Story (Backlog Item) What user or stakeholder need will the story serve? How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love The Planning Onion can grow to include product portfolios and business strategy Product or Project Release Sprint Story © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 23 Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love The Planning Onion can grow to include product portfolios and business strategy Business Strategy Product Portfolio Product or Project Release Sprint Story © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24 Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love The software we choose to build is a consequence of smaller upstream choices Choices in business goals, users, and use have big consequences to software scope Business Goals User Constituencies Use (Activities & Tasks) Software to build (Specified as User Stories) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Segmenting scope into incremental releases also segments use, user goals, and business goals Work top down (goals to scope) or bottom up (scope back to goals), but always work to ensure you’re delivering scope that delivers on business and user goals Business Goals User Constituencies Use (Activities & Tasks) Software to build (Specified as User Stories) 1 2 3 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love We’ll plan using a story map that describes use in activities, tasks, and task details – but first we need to build the story map Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love By arranging activity and task cards spatially, we can tell bigger stories Tell a big story of the KNOW release by starting with the user activities the relevant to this release Arrange activities left to right in the order you’d explain them to someone when asked the question: “What do people do with this system? time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love By arranging activity and task cards spatially, we can tell bigger stories Add task-centric stories in under each activity in chronological order left to right. If you were to explain to someone what a person typically does in this activity, arrange tasks in the order you’d tell the story time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love As details emerge in conversation, trap them under there associated task cards Record details so their not lost, and so those that you’re working with know that you’re listening Consider tucking them under tasks cards to “hide them” from the discussion time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Build a story map from the KNOW product backlog Incremental Releases Users & Stakeholders Will Love Build a story map from the KNOW product backlog Leverage Zanub as a KNOW subject matter expert User Activity (big thing) time User Task (simple achievable action in the system) Detail (detail of that task) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Moving forward with a subject I’ve been avoiding: Requirements Jeff Patton, jpatton@acm.org

In software development, what is a “requirement”? Incremental Releases Users & Stakeholders Will Love In software development, what is a “requirement”? In small groups, discuss the definition of requirement. Write a working definition for your group. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Consider our hierarchy and requirements Incremental Releases Users & Stakeholders Will Love Consider our hierarchy and requirements Business goals result in business level requirements to reach specific business objectives, solve business problems, or be in regulatory compliance. User models help us identify what users desire to be successful. Looking at users’ activities and tasks helps us identify functional requirements. Looking at user characteristics helps us identify design imperatives – or non-functional requirements related to use Activity & Task models help us identify details of usage and begin to make decisions about which uses to support or not support. (detailed functional requirements and scope boundaries) Discussions of use often reveal business rules or usage constraints. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love For the purpose of our conversation, consider a “requirement” to be a decision “The hardest single part of building a software system is deciding precisely what to build.” -- Fred Brooks In his 1987 essay “No Silver Bullet” "A requirement is a relationship to a decision: If you get to make or change the decision, it's design to you; if you don't get to make or change that decision, it's a requirement to you." -- Alistair Cockburn © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Why do “requirements” change? Incremental Releases Users & Stakeholders Will Love Why do “requirements” change? In small groups, discuss the reasons that requirements change. Make a list of reasons and prioritize them – most likely to change highest. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Building architects alternate between the words requirements and design constraints Consider these sources of architectural design constraints. Constraints may come from: Users (their characteristics, goals, and usage) Clients (business and their goals) Outside regulatory agencies Engineering (tools, materials, and building practice) Constraints can be relaxed or changed. Consider the sources of constraints above. Order thes sources from easiest to change to hardest. Why would it be easier to change constraints from one source over another? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Requirements are malleable As a product owner you’ll make decisions that change requirements for the team creating the software Make decisions that preserve the goals of the project within the projects timebox Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Now that I’ve hopefully given you a broader definition of requirement, I’d like to give you a new broader definition of quality Jeff Patton, jpatton@acm.org

Considering feature quality characteristics Incremental Releases Users & Stakeholders Will Love Considering feature quality characteristics Given a user task like “swing from tree,” a variety of feature design solutions exist to support the task which vary widely Managing feature details appropriately is an important part of managing scope When initially planning the delivery of a set of features, the characteristics of each feature must be considered Much of detail scope management happens during design and development Close to the time the functionality is needed In the context of other features, time constraints, development capacity, and other projects in the portfolio low cost moderate cost high cost © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Noriaki Kano asks 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 objective-subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” --Noriaki Kano © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love 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 happy One dimensionals The more of this I get, the better Delighters I love this element of the product! “This car has many flaws. Buy it anyway. It’s so much fun to drive” -- from a NY Times review of the Mini Cooper © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Separate objective quality from subjective quality Incremental Releases Users & Stakeholders Will Love 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 made that 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? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love The Car Metaphor Consider the job of building a car incrementally. Omitting necessary features may make the product useless – this makes prioritization difficult. We need to perform every user task these features are built to support. Scaling all features to highest quality level increases cost To control the cost of the car, we scale the features back to economical quality levels Feature List Engine Transmission Tires Suspension Brakes Steering wheel Driver’s seat … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

The characteristics of a feature used for managing scope Incremental Releases Users & Stakeholders Will Love The characteristics of a feature used for managing scope Necessity: what minimal characteristics are necessary for this feature? For our car a minimal engine and transmission are necessary – along with a number of other features. Flexibility: what would make this feature more useful in more situations? For our car, optional all-wheel-drive would make it more useful for me to take on camping trips. A hatchback might make it easier for me to load bigger stuff into the back. Safety: what would make this feature safer for me to use? For our car adding seat belts and making the brakes anti-locking would make the car safer. Comfort, Luxury, and Performance: what would make this feature more desirable to use? I’d really like automatic climate control, the seats to be leather, and a bigger V6 engine. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love When Planning a Software Release, Thin Software Features Using the Same Guidelines When planning a software release, start with tasks that users must perform Add in flexibility tasks as necessary Add in safety tasks as necessary Add in comfort, luxury, and performance as it benefits return on software investment © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Use Feature Thinning Guidelines to Reduce the Size of a Release Incremental Releases Users & Stakeholders Will Love Use Feature Thinning Guidelines to Reduce the Size of a Release The topmost row of the span could be the first, smallest release By minimizing a release we can realize financial and risk reduction benefits earlier The top span represents the minimal tasks users need to accomplish to reach their goals. How can we split these “high level stories” into smallest parts? Can the feature(s) to support a task have reduced safety? Can the feature(s) to reduce a task have less comfort, performance, and luxury? Are there optional tasks that can be supported in a subsequent release? For necessary tasks, look at the steps – or subtasks that make up the task. Can any of those steps be made optional? Move cards around the model, or split cards into multiple cards to defer task support, or specific feature characteristics till later releases © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Splitting tasks in Story Maps Incremental Releases Users & Stakeholders Will Love Splitting tasks in Story Maps activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional Consider tasks more optional Split tasks into optional parts © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Translate the KNOW model into an incremental release plan Incremental Releases Users & Stakeholders Will Love Translate the KNOW model into an incremental release plan Create horizontal swim-lanes to group features into releases Arrange features vertically by necessity in the system Split tasks into parts that can be deferred till later releases necessary less optional optionality more optional © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Turn the segmented scope into a milestone plan Incremental Releases Users & Stakeholders Will Love Turn the segmented scope into a milestone plan For each release candidate give the release: a name describe how the business benefits on delivery of the release indicate which users are affected, and how they benefit for each release time necessary less optional optionality more optional © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Effective planning takes into account users and use along with business goals The planning approach we’ve practiced leverages our story map to prioritize in the context of all system activities and tasks. Road-mapping builds back up to user and business goals by answering the question for each release: what value does the business get? what value do users get? EasyPOS Point of Sale Software Business: replaces gets rid of old manual cash registers and gets accurate up the minute sales information across locations Release 1: Replace the cash register Users: Cashiers get an easier to use cash register that helps them make less mistakes, correct them when they do, and save time balancing cash drawers every night. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Effective planning takes into account users and use along with business goals Activities & key tasks Milestone What business gets (orange) Users Business Goals What users get (yellow) task in scope (purple) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Tactical Product Ownership day 2: user stories, iterative, and incremental development Jeff Patton AgileProductDesign.com jpatton@acm.org Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Over the past years, User Stories have evolved to be the preferred way to specify software to build in an Agile environment Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Agile development delivers incrementally by breaking up functionality into small pieces Small pieces can be referred to as items in a backlog of work (backlog items) – or more commonly today as user stories User stories are often written on index cards * Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Agile development reduced batch size by breaking up functionality into smaller pieces A good story describes what the system should do from the users perspective. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Agile development reduced batch size by breaking up functionality into smaller pieces A good story describes what the system should do from the users perspective. It usually has: a title a concise problem statement: As a [type of user] I want to [perform some task] so that [I can reach some goal or get some benefit] other relevant notes or sketches We can inherit the user type and the basic goal from the activity the story supports. Try telling stories in this form from your story map. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Stories support users and use to achieve business goals Incremental Releases Users & Stakeholders Will Love Stories support users and use to achieve business goals software organization (goals) problem context software users (goals) use (tasks) software software solution We’ve described our problem and solution space with this simple model… © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Stories support users and use to achieve business goals Incremental Releases Users & Stakeholders Will Love Stories support users and use to achieve business goals We model business goals, users, user activities and user tasks to understand the problem context. We write stories to implement software solutions that allows users to reach those business goals. Business Goal User User Activity Activity Task Task Task Task Task Task story story story story story story story story story story © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Stories support users and use to achieve business goals Incremental Releases Users & Stakeholders Will Love Stories support users and use to achieve business goals We model business goals, users, user activities and user tasks to understand the problem context. We write stories to implement software solutions that allows users to reach those business goals. Business Goal High level user stories suitable for planning User User Activity Activity Task Task Task Task Task Task story story story story story story story story story story © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Evaluate the quality of stories using INVEST Incremental Releases Users & Stakeholders Will Love Evaluate the quality of stories using INVEST The INVEST test allows us to evaluate our stories: Independent Negotiable Valuable Estimable Small Testable * Bill Wake coined the INVEST approach to testing story quality © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Large stories may be split by using story thinning guidelines Incremental Releases Users & Stakeholders Will Love Large stories may be split by using story thinning guidelines Necessity: what elements of the story are necessary for users to reach their goal, and for business to receive some value? Flexibility: what elements of the story afford the user alternative ways to do things or more options? Safety: what elements of the story make things safer for the user or the protect the business from user errors or malicious use? Comfort, performance, & luxury: what elements make the story nicer to use, faster to use, better to look at, or more delightful? Discuss story splitting along these “perforation points” Split stories only when it offers sufficient benefit, or doesn’t inject unnecessary risk to the product © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Split larger task-centric stories into smaller sprint level stories Incremental Releases Users & Stakeholders Will Love Split larger task-centric stories into smaller sprint level stories Discuss these two large KNOW stories split them into smaller sized stories that follow INVEST guidelines use story thinning guidelines to find “perforation points” to help split Note, that the stories will need more discussion before they can be split As a document-reader I want to view documents I need to rate so that I can easily rate documents I’ve downloaded to be a good KNOW citizen, and stop KNOW from nagging me As a document reader I want to rate a document so that I can be a good KNOW citizen, stop KNOW from nagging me, and share my knowledge with others. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love To prepare a story for a sprint, we need to describe it’s acceptance criteria Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love A user story goes through a simple lifecycle to grow to become more like “requirements” A story goes through a simple elaboration cycle of: card: write the initial story text on the card conversation: discuss the details with developers, analysts, and testers confirmation: record the acceptance tests that will allow us to know when the story is complete * Ron Jeffries coined the 3 C’s in Extreme Programming Installed © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love For the sprint level stories you’ve written, have a conversation with developers to write acceptance Divide into groups of three One person take on the role of developer. Another take on the role of tester, Another take on the role of business analyst. Discuss the story answering the question: “How will we determine this story is done?" Write a list of the things you’ll check to assess “doneness.” Try using the template: given [precondition] when [user performs some action] then [some result can be observed] © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Sprint stories are use to build software driving towards release goals Jeff Patton, jpatton@acm.org

The Simple Scrum Process Model Incremental Releases Users & Stakeholders Will Love The Simple Scrum Process Model It’s called “the snowman model” (see the snowman?) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

What does potentially shippable really mean? Incremental Releases Users & Stakeholders Will Love What does potentially shippable really mean? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love These day’s we don’t usually plan to release the outcome of single sprint So let’s look at Agile time-boxed development a bit differently Jeff Patton, jpatton@acm.org

The basic anatomy of an Agile iteration Incremental Releases Users & Stakeholders Will Love The basic anatomy of an Agile iteration plan perform evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

The basic anatomy of an Agile iteration Incremental Releases Users & Stakeholders Will Love The basic anatomy of an Agile iteration Development supported by: automated unit tests automated acceptance tests Sprint Planning Meeting Sprint Plan User Stories Development Task Creation Estimation plan perform evaluate An Agile iteration is generally 1-4 weeks, or 1 calendar month objective: plan, create, and validate deliverable functionality Product Demonstration Creation of Additional User Stories Measurement of Team Velocity Team Retrospective © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

An iteration has it’s plan-perform- evaluate cycle Incremental Releases Users & Stakeholders Will Love An iteration has it’s plan-perform- evaluate cycle perform Iteration plan evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 73 Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Performing an iteration means discussing, writing code for, and validating user stories code Story design validate perform Iteration plan evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 74 Jeff Patton, jpatton@acm.org

Releasing software incrementally means building software iteratively Incremental Releases Users & Stakeholders Will Love Releasing software incrementally means building software iteratively code Story design validate Iteration plan evaluate Release plan evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Chartering a product or project means determining how to release it incrementally Notice the layers of planning and evaluation All this planning and evaluation lends lots of opportunity for course correction Notice how planning and evaluation moves from course grain to fine grain, and from abstract to detailed code Story precise, fine grained, detailed design validate Iteration plan evaluate Release Product/Project plan evaluate abstract, course grained, and high level plan evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76 Jeff Patton, jpatton@acm.org

We can flatten these nested cycles to see how they look over time. Incremental Releases Users & Stakeholders Will Love We can flatten these nested cycles to see how they look over time. product release release iteration daily story development cycles time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 Jeff Patton, jpatton@acm.org

The “definition of done” varies at each cycle Incremental Releases Users & Stakeholders Will Love The “definition of done” varies at each cycle Product/Project Release Iteration plan evaluate Story design code validate abstract, course grained, and high level precise, fine grained, detailed What is “done” for a story? What is “done” for a sprint? What is “done” for a release? What is “done” for a product? For each level of done consider: what does done mean? specifically what activities will we do to test for done-ness? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Iterating and incrementing are two different strategies, You’ll need to leverage both. Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Jeff, tell Roger’s story here. Jeff Patton, jpatton@acm.org

“incrementing” builds a bit at a time Incremental Releases Users & Stakeholders Will Love “incrementing” builds a bit at a time Incrementing often calls for a fully formed idea 1 2 3 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love once development starts, a common failure mode of agile development is to incrementally design and build each feature at the end of a release timebox, all features supporting user tasks are not implemented the release isn’t useful to end users end to end functionality may never have been validated: from a functional, architectural, or usability perspective this seems like the obvious approach – it’s easiest – but it’s risky – unless you know exactly what you’re going to build and exactly how long it’ll take release user tasks to support iterations design & development 1 2 3 4 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love “iterating” builds a rough version, then slowly builds up quality as we validate requirements Iterating allows you to move from vague idea to realization 1 2 3 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

use feature thinning guidelines to grow features iteratively Incremental Releases Users & Stakeholders Will Love use feature thinning guidelines to grow features iteratively each feature you design has some measure of necessity, flexibility, safety, comfort, performance, and luxury start by making sure that each feature is designed and implemented to support necessary, or essential use after sufficiently completing necessities, continue by adding flexibility and safety conclude by adding comfort, performance, and luxury to the features that can most benefit release user tasks to support iterations design & development 1 2 3 4 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love this strategy has us designing each feature many times over growing and changing the software as we learn from each iteration’s design and development the resulting release has support for all users’ tasks up to a usable level complete workflow was visible earlier in the release: this allows for functional, architectural, and preliminary usability evaluation there’s never enough time to implement all the flexibility, safety, comfort, performance and luxury you’d hoped… strive for sufficiency this is hard work you’ll design features over many times, but we’ve significantly reduced risk iterations design & development 1 2 3 4 user tasks to support release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Make quality improvement visible by managing the “gpa” of your release Incremental Releases Users & Stakeholders Will Love Make quality improvement visible by managing the “gpa” of your release Grade the quality of release level stories as your release progresses. Don’t aim for all iteration level stories complete – aim for sufficient release quality B- C C- D A- B B- D I A- A B B- release user tasks to support iterations design & development 1 2 3 4 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

The closer we get to implementing features, the more we know Incremental Releases Users & Stakeholders Will Love The closer we get to implementing features, the more we know Barry Boehm first described the cone of uncertainty applying it to estimation accuracy over time Steve McConnell applied the same principle to certainty of product requirements Defer specific feature decisions to the “latest responsible moment” as described in Poppendiek & Poppendiek’s Lean Software Development uncertainty uncertainty decreases over time time cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Divide release design & development into “trimesters” Incremental Releases Users & Stakeholders Will Love Divide release design & development into “trimesters” Build a simple system span of necessary features first Add flexibility and safety next Finish with comfort, performance, and luxury Reserve time in the remaining third for unforeseen additions and adaptations Necessity Flexibility and Safety Comfort, Performance, Luxury, and unforeseen additions and adaptations uncertainty uncertainty decreases over time time cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

This product thickening strategy slowly brings the product into focus Incremental Releases Users & Stakeholders Will Love This product thickening strategy slowly brings the product into focus Just as 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 “thicken” the product from simple necessities through to full featured product. time uncertainty decreases over time uncertainty Necessity Flexibility and Safety Comfort, Performance, Luxury, and unforeseen additions and adaptations © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

What strategies do you use for iteration? Incremental Releases Users & Stakeholders Will Love What strategies do you use for iteration? Possible strategies include: Iterating in low fidelity UI prototypes before implementing stories Saving sprints at the end of the release for “feedback” Architectural “spikes” to prototype architectural concepts before committing to them What else? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Revisiting our goals: Move from conceptual analysis and scope definition to detailed Agile project work Plan a project composed of multiple thinned releases Split larger planning grade stories into sprint level stories Develop acceptance criteria for those stories Properly exploit iteration in Agile development Jeff Patton, jpatton@acm.org

Incremental Releases Users & Stakeholders Will Love Tactical Product Ownership day 2: iterative and incremental development Jeff Patton AgileProductDesign.com jpatton@acm.org Jeff Patton, jpatton@acm.org