Presentation is loading. Please wait.

Presentation is loading. Please wait.

Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com

Similar presentations


Presentation on theme: "Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com"— Presentation transcript:

1 Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com

2 © Jeff Patton, All rights reserved, 2 The ground weve 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.

3 3 Our goals for the next two days: Move from conceptual analysis and scope definition to detailed Agile project work 1.Plan a project composed of multiple thinned releases 2.Split larger planning grade stories into sprint level stories 3.Develop acceptance criteria for those stories 4.Properly exploit iteration in Agile development

4 4 candle dipping

5 5 Starting with where weve been

6 © Jeff Patton, All rights reserved, 6 software The software we choose to build fits in a product shaped hole software use (tasks) users (goals) organization (goals) problem context software solution The quality of the product is a function of how well it fits inside its problem context.

7 7 The software we choose to build fits in a product shaped hole software use (activities & tasks) users (goals) organization (goals) problem context software solution The quality of the product is a function of how well it fits inside its problem context. customer (value proposition) © Jeff Patton, All rights reserved,

8 8 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

9 © Jeff Patton, All rights reserved, 9 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

10 © Jeff Patton, All rights reserved, 10 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

11 © Jeff Patton, All rights reserved, 11 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

12 © Jeff Patton, All rights reserved, 12 We learned techniques to model each layer of the problem context 1. Identify goals that motivate creation of the product 2.Use why questions to find goals that track back to increasing revenue or reducing cost 3.Use the question how would we know if we were making progress towards this goal to identify metrics 1. Identify types of users as roles relative to the business, a process, or the solution 2. Identify characteristics of these groups relevant to the solution 3. Build a persona leveraging those details 4.Identify feature ideas and product design imperatives 1. Identify large collections of related tasks as activities 2. Identify tasks within those activities 3. Record details of tasks 4. Arrange activities and tasks into a typical workflow order

13 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 C- Level Participants C-Level Assistants Event Coordinator Event Planner Editor I want to network with colleagues that can help me with goals and problems Im facing in my company My boss spends most of his time in meetings and traveling. Its 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. McKinseys reputation, and the quality of interaction we have with CSOs relies on relevant high quality content. GOALS USER CONSTITUENTS USER ACTIVITIES 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

14 © Jeff Patton, All rights reserved, 14 Solution inception alternates between analyzing the problem context and exploring possible solutions 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. business problems & goals analysis user research user modeling activity & task analysis (how do users achieve goals today?) activity and task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing idea incremental release strategy time

15 © Jeff Patton, All rights reserved, 15 idea incremental release strategy Solutions design alternates between analyzing the problem context and exploring possible solutions 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. business problems & goals analysis user research user modeling activity & task analysis (how do users achieve goals today?) activity and task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing time

16 © Jeff Patton, All rights reserved, 16 idea incremental release strategy Solutions design alternates between analyzing the problem context and exploring possible solutions 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. business problems & goals analysis user research user modeling activity & task analysis (how do users achieve goals today?) activity and task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing time

17 © Jeff Patton, All rights reserved, 17 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 youre working on? Have you been able to practice approaches to: elicitation facilitation collaboration

18 © Jeff Patton, All rights reserved, 18 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

19 19 Incremental release planning, second dip

20 © Jeff Patton, All rights reserved, 20 The product owner plans the product in layers

21 © Jeff Patton, All rights reserved, 21 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 its completed? Story Details Acceptance Tests

22 © Jeff Patton, All rights reserved, 22 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 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 its completed? Story Details Acceptance Tests Product or Project Release Sprint Story

23 © Jeff Patton, All rights reserved, 23 The Planning Onion can grow to include product portfolios and business strategy Product or Project Release Sprint Story © Jeff Patton, All rights reserved, 23

24 © Jeff Patton, All rights reserved, 24 Product or Project Release Sprint Story The Planning Onion can grow to include product portfolios and business strategy Product Portfolio Business Strategy © Jeff Patton, All rights reserved, 24

25 © Jeff Patton, All rights reserved, 25 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 Use (Activities & Tasks) Software to build (Specified as User Stories) User Constituencies Business Goals

26 © Jeff Patton, All rights reserved, 26 Segmenting scope into incremental releases also segments use, user goals, and business goals Use (Activities & Tasks) Software to build (Specified as User Stories) User Constituencies Business Goals 123 Work top down (goals to scope) or bottom up (scope back to goals), but always work to ensure youre delivering scope that delivers on business and user goals

27 27 Well plan using a story map that describes use in activities, tasks, and task details – but first we need to build the story map

28 © Jeff Patton, All rights reserved, 28 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 youd explain them to someone when asked the question: What do people do with this system? time

29 © Jeff Patton, All rights reserved, 29 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 youd tell the story time

30 © Jeff Patton, All rights reserved, 30 As details emerge in conversation, trap them under there associated task cards Record details so their not lost, and so those that youre working with know that youre listening Consider tucking them under tasks cards to hide them from the discussion time

31 © Jeff Patton, All rights reserved, 31 Build a story map from the KNOW product backlog Leverage Zanub as a KNOW subject matter expert time User Activity (big thing) User Task (simple achievable action in the system) Detail (detail of that task)

32 32 Moving forward with a subject Ive been avoiding: Requirements

33 © Jeff Patton, All rights reserved, 33 In software development, what is a requirement? In small groups, discuss the definition of requirement. Write a working definition for your group.

34 © Jeff Patton, All rights reserved, 34 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.

35 © Jeff Patton, All rights reserved, 35 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

36 © Jeff Patton, All rights reserved, 36 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.

37 © Jeff Patton, All rights reserved, 37 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?

38 38 Requirements are malleable As a product owner youll make decisions that change requirements for the team creating the software Make decisions that preserve the goals of the project within the projects timebox

39 39 Now that Ive hopefully given you a broader definition of requirement, Id like to give you a new broader definition of quality

40 © Jeff Patton, All rights reserved, 40 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 costmoderate costhigh cost

41 © Jeff Patton, All rights reserved, 41 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

42 © Jeff Patton, All rights reserved, 42 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. Its so much fun to drive -- from a NY Times review of the Mini Cooper

43 © Jeff Patton, All rights reserved, 43 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?

44 © Jeff Patton, All rights reserved, 44 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 Drivers seat …

45 © Jeff Patton, All rights reserved, 45 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? Id really like automatic climate control, the seats to be leather, and a bigger V6 engine.

46 © Jeff Patton, All rights reserved, 46 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

47 © Jeff Patton, All rights reserved, 47 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

48 © Jeff Patton, All rights reserved, 48 Splitting tasks in Story Maps Consider tasks more optional Split tasks into optional parts time optionality necessary less optional more optional activity 1activity 2activity 3activity 4

49 © Jeff Patton, All rights reserved, 49 Translate the KNOW model into an incremental release plan 1.Create horizontal swim-lanes to group features into releases 2.Arrange features vertically by necessity in the system 3.Split tasks into parts that can be deferred till later releases optionality necessary less optional more optional

50 © Jeff Patton, All rights reserved, 50 Turn the segmented scope into a milestone plan For each release candidate give the release: 1.a name 2.describe how the business benefits on delivery of the release 3.indicate which users are affected, and how they benefit for each release time optionality necessary less optional more optional

51 © Jeff Patton, All rights reserved, 51 Effective planning takes into account users and use along with business goals The planning approach weve 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 Release 1: Replace the cash register Business: replaces gets rid of old manual cash registers and gets accurate up the minute sales information across locations 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. EasyPOS Point of Sale Software Release 1: Replace the cash register Business: replaces gets rid of old manual cash registers and gets accurate up the minute sales information across locations 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.

52 © Jeff Patton, All rights reserved, 52 Effective planning takes into account users and use along with business goals Business Goals Users Activities & key tasks What users get (yellow) What business gets (orange) task in scope (purple) Milestone

53 Tactical Product Ownership day 2: user stories, iterative, and incremental development Jeff Patton AgileProductDesign.com

54 54 Over the past years, User Stories have evolved to be the preferred way to specify software to build in an Agile environment

55 © Jeff Patton, All rights reserved, 55 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 1 st Edition, 1999

56 © Jeff Patton, All rights reserved, 56 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.

57 © Jeff Patton, All rights reserved, 57 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.

58 © Jeff Patton, All rights reserved, 58 Stories support users and use to achieve business goals software use (tasks) users (goals) organization (goals) problem context software solution Weve described our problem and solution space with this simple model…

59 © Jeff Patton, All rights reserved, 59 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 Activity Task User Task story

60 © Jeff Patton, All rights reserved, 60 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 Activity Task User Task story High level user stories suitable for planning

61 © Jeff Patton, All rights reserved, 61 Evaluate the quality of stories using INVEST The INVEST test allows us to evaluate our stories: I ndependent N egotiable V aluable E stimable S mall T estable * Bill Wake coined the INVEST approach to testing story quality

62 © Jeff Patton, All rights reserved, 62 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 doesnt inject unnecessary risk to the product

63 © Jeff Patton, All rights reserved, 63 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 Ive 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.

64 64 To prepare a story for a sprint, we need to describe its acceptance criteria

65 © Jeff Patton, All rights reserved, 65 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 Cs in Extreme Programming Installed

66 © Jeff Patton, All rights reserved, 66 For the sprint level stories youve 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 youll check to assess doneness. Try using the template: given [precondition] when [user performs some action] then [some result can be observed]

67 67 Sprint stories are use to build software driving towards release goals

68 © Jeff Patton, All rights reserved, 68 The Simple Scrum Process Model Its called the snowman model (see the snowman?)

69 © Jeff Patton, All rights reserved, 69 What does potentially shippable really mean?

70 70 These days we dont usually plan to release the outcome of single sprint So lets look at Agile time-boxed development a bit differently

71 © Jeff Patton, All rights reserved, 71 The basic anatomy of an Agile iteration planperform evaluate

72 © Jeff Patton, All rights reserved, 72 The basic anatomy of an Agile iteration planperform evaluate Sprint Planning Meeting Sprint Plan User Stories Development Task Creation Estimation Development supported by: automated unit tests automated acceptance tests Product Demonstration Creation of Additional User Stories Measurement of Team Velocity Team Retrospective An Agile iteration is generally 1-4 weeks, or 1 calendar month objective: plan, create, and validate deliverable functionality

73 © Jeff Patton, All rights reserved, 73 Iteration An iteration has its plan-perform- evaluate cycle © Jeff Patton, All rights reserved, 73 plan perform evaluate

74 © Jeff Patton, All rights reserved, 74 Iteration Performing an iteration means discussing, writing code for, and validating user stories © Jeff Patton, All rights reserved, 74 plan perform evaluate Story design code validate

75 © Jeff Patton, All rights reserved, 75 Release Iteration Releasing software incrementally means building software iteratively © Jeff Patton, All rights reserved, 75 planevaluate Story design code validate plan evaluate

76 © Jeff Patton, All rights reserved, 76 Product/Project Release Iteration Chartering a product or project means determining how to release it incrementally © Jeff Patton, All rights reserved, 76 planevaluate Story design code validate plan evaluate plan evaluate 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 abstract, course grained, and high level precise, fine grained, detailed

77 © Jeff Patton, All rights reserved, 77 We can flatten these nested cycles to see how they look over time. product © Jeff Patton, All rights reserved, 77 release iteration daily story development cycles time

78 © Jeff Patton, All rights reserved, 78 The definition of done varies at each cycle © Jeff Patton, All rights reserved, Product/Project Release Iteration planevaluate Story design code validate plan evaluate plan evaluate 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?

79 79 Iterating and incrementing are two different strategies, Youll need to leverage both.

80 80 Jeff, tell Rogers story here.

81 © Jeff Patton, All rights reserved, 81 incrementing builds a bit at a time 123 Incrementing often calls for a fully formed idea

82 © Jeff Patton, All rights reserved, 82 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 isnt 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 – its easiest – but its risky – unless you know exactly what youre going to build and exactly how long itll take iterations design & development user tasks to support release

83 © Jeff Patton, All rights reserved, 83 iterating builds a rough version, then slowly builds up quality as we validate requirements 123 Iterating allows you to move from vague idea to realization

84 © Jeff Patton, All rights reserved, 84 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 iterations design & development user tasks to support release

85 © Jeff Patton, All rights reserved, 85 this strategy has us designing each feature many times over growing and changing the software as we learn from each iterations 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 theres never enough time to implement all the flexibility, safety, comfort, performance and luxury youd hoped… strive for sufficiency this is hard work youll design features over many times, but weve significantly reduced risk iterations design & development user tasks to support release

86 © Jeff Patton, All rights reserved, 86 Make quality improvement visible by managing the gpa of your release Grade the quality of release level stories as your release progresses. Dont aim for all iteration level stories complete – aim for sufficient release quality iterations design & development user tasks to support release DDDDDIIB-CC-DDDDA-BB-BBB A-ABA B-

87 © Jeff Patton, All rights reserved, 87 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 & Poppendieks Lean Software Development time uncertainty decreases over time cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements) uncertainty

88 © Jeff Patton, All rights reserved, 88 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 time uncertainty decreases over time cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements) uncertainty Necessity Flexibility and Safety Comfort, Performance, Luxury, and unforeseen additions and adaptations

89 © Jeff Patton, All rights reserved, 89 time uncertainty decreases over time uncertainty Necessity Flexibility and Safety Comfort, Performance, Luxury, and unforeseen additions and adaptations 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.

90 © Jeff Patton, All rights reserved, 90 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?

91 91 Revisiting our goals: Move from conceptual analysis and scope definition to detailed Agile project work 1.Plan a project composed of multiple thinned releases 2.Split larger planning grade stories into sprint level stories 3.Develop acceptance criteria for those stories 4.Properly exploit iteration in Agile development

92 Tactical Product Ownership day 2: iterative and incremental development Jeff Patton AgileProductDesign.com


Download ppt "Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com"

Similar presentations


Ads by Google