Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Scrum Product Owner Practice Surviving the Agile rollercoaster as part of a product owner team Jeff Patton AgileProductDesign.com.

Similar presentations


Presentation on theme: "The Scrum Product Owner Practice Surviving the Agile rollercoaster as part of a product owner team Jeff Patton AgileProductDesign.com."— Presentation transcript:

1 The Scrum Product Owner Practice Surviving the Agile rollercoaster as part of a product owner team Jeff Patton AgileProductDesign.com

2 © Jeff Patton, All rights reserved, 2 ©Alistair Cockburn Slide3 PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency Level 1:following (shu) Learn a technique that works (Success = following the technique) Level 2:breaking away (ha ) Learn limits of the technique Learn to shift between techniques Level 3:fluent ( ri ) Shift techniques at any moment Possibly unable to describe the shifts We will use this progression throughout the course.

3 3 Today Ill cover 3 areas 1. Models to help us understand product design 2. Practice that supports product design 3. Product design practice in the Scrum Product Owner team

4 4 Before we start, on a bit of paper, or in a notebook, write down your biggest, most burning question regarding: Scrum, Agile Development, the Product Owner Role, or life in general.

5 © Jeff Patton, All rights reserved, 5 By Design I mean the decisions we make regarding the software solution we choose to build. 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

6 6 Garretts Elements of User Experience Model describes a series of dependent decisions.

7 © Jeff Patton, All rights reserved, 7 Software user experience is built from dependent layers Jesse James Garretts Elements of User Experience:

8 © Jeff Patton, All rights reserved, 8 The surface layer describes finished visual design aspects Surface Skeleton Structure Scope Strategy

9 © Jeff Patton, All rights reserved, 9 The skeleton describes screen layout and functional compartments in the screen Surface Skeleton Structure Scope Strategy

10 © Jeff Patton, All rights reserved, 10 Structure defines navigation from place to place in the user interface task panes modal dialogs modal wizards Surface Skeleton Structure Scope Strategy

11 © Jeff Patton, All rights reserved, 11 The places in the user interface are built to support user-task-centric scope user tasks: enter numbers enter text enter formulas format cells sort information filter information aggregate information graph data save data import data export data print ….. Surface Skeleton Structure Scope Strategy

12 © Jeff Patton, All rights reserved, 12 Business goals drive user constituencies choices and contexts supported to form strategy business goals: displace competitive products motivate sale of other integrated products establish file format as default information sharing format … user constituencies: accountant business planner housewife … usage contexts: office desktop laptop on airplane pda in car … Surface Skeleton Structure Scope Strategy

13 © Jeff Patton, All rights reserved, 13 Garrets Elements of UX stack can apply to the user experience of other complex products These layers of concern apply not only to software but a variety of products. In particular, products that support a wide variety of user tasks benefit from this kind of thinking.

14 © Jeff Patton, All rights reserved, 14 Lets look at the strategy for a product we all use: the place we live goals: live comfortably eat well stay clean be healthy keep up with Joness … user constituencies: me spouse child … usage contexts: suburban neighborhood near good schools near shopping … Surface Skeleton Structure Scope Strategy

15 © Jeff Patton, All rights reserved, 15 What might I, and my other user constituencies, do to reach our goals? user tasks: store food prepare food eat food sleep bathe store changes of clothing stay out of rain entertain guests entertain self … Surface Skeleton Structure Scope Strategy

16 © Jeff Patton, All rights reserved, 16 Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy

17 © Jeff Patton, All rights reserved, 17 When designing a particular interaction context such as a kitchen, I optimize layout and tool choices to support tasks Ill do there Surface Skeleton Structure Scope Strategy

18 © Jeff Patton, All rights reserved, 18 Im going to spend a lot of time here, I want my experience to be as pleasant as possible… Surface Skeleton Structure Scope Strategy

19 19 Underneath Garretts model is a simple 3 layer model

20 © Jeff Patton, All rights reserved, 20 Normans simple model for a human in pursuit of a goal problem or goal How Id like to feel, or what Id like to achieve take some action action evaluation did that action deliver that results I expected? goal evaluation is my goal met or problem resolved? the world information and tools

21 © Jeff Patton, All rights reserved, 21 Distilling this down to goals, tasks, and tools problem or goal How Id like to feel, or what Id like to achieve the world information and tools take some action action evaluation did that action deliver that results I expected? goal evaluation is my goal met or problem resolved? goal task tool

22 © Jeff Patton, All rights reserved, 22 software Software contains features that support a number of tasks and a number of goals goals tasks toolsfeatures

23 23 One last model looks at a design process that alternates between problem analysis and solution definition

24 © Jeff Patton, All rights reserved, 24 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. time business problems & goals analysis user research user modeling task analysis (how do users achieve goals today?) task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing

25 © Jeff Patton, All rights reserved, 25 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. time business problems & goals analysis user research user modeling task analysis (how do users achieve goals today?) task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing

26 26 Now lets look at practices that a product owner users to move from problem analysis through to solution definition

27 © Jeff Patton, All rights reserved, 27 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

28 © Jeff Patton, All rights reserved, 28 Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isnt completeness or accuracy, but communication For our purposes: a model is any visual representation of our current understanding of a concept Well build models to understand our problem context, and explore solutions

29 © Jeff Patton, All rights reserved, 29 Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding

30 © Jeff Patton, All rights reserved, 30 Representing our ideas as models allows us to detect inconsistencies in our understanding

31 © Jeff Patton, All rights reserved, 31 Through discussion and iterative model building we arrive at a stronger shared understanding

32 © Jeff Patton, All rights reserved, 32 Using that common understanding we can work together toward shared objectives

33 © Jeff Patton, All rights reserved, 33 Low fidelity card models are used to facilitate discussions and build common understanding Common model forms include: Affinity diagrams Chronological models Decompositions Ad hoc charts Mix and match as you see fit

34 © Jeff Patton, All rights reserved, 34 Collaborative modeling looks like this

35 © Jeff Patton, All rights reserved, Collaborative modeling sessions follow a simple, repeatable structure 2 3 Use Collaborative Modeling Sessions to: Build up tacit shared knowledge within the team Build communication and collaboration skills within the team Help the team to gel as an affective workgroup Prepare Write a short statement to set goals and scope for the session Identify participants – 4-8 is ideal Fill These Roles: Information Suppliers Information Acquirers Information Modelers Facilitator Documenter Schedule & set up work session facility Perform Kickoff with goals and scope Get information figuratively and literally on the table using brainstorming or discussion Model the information to clarify, add details, distill details, and understand relationships Close by summarizing the results, on camera if possible Document & Communicate Capture model with photo and/or movie Document as necessary Post in publicly accessible place Display as a poster

36 © Jeff Patton, All rights reserved, 36 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

37 37 Business objectives describes why wed choose to buy or build the software

38 © Jeff Patton, All rights reserved, 38 Look for benefit to the buyer or builder of the software For software built for internal use: Save money Increase efficiency Solve problems that are costing money or decreasing efficiency Improve customer satisfaction Generate revenue by supporting or improving service offerings For software built for commercial sale: Generate revenue through sale Improve/expand market share Open new markets The IRACIS* mnemonic helps us remember to look for business benefit that will Increase Revenue Avoid Cost Increase Service * Gane & Sarsons IRACIS model, 1977

39 © Jeff Patton, All rights reserved, 39 When asking for business goals look for expressions of business problems or desired outcomes Express goals as business problems or business outcomes Its tempting for business stakeholders or users to describe their proposed solution as a goal Solution-centric goal: Id like a cost effective ski parka Problem-centric goal: Id like to stay warm and dry while skiing Use root cause analysis to get behind solutions to goals and problems Toyotas 5 whys describes root cause analysis Poking it with the why stick is often what my colleagues say

40 © Jeff Patton, All rights reserved, 40 Use a Goal Question Metric approach to identify appropriate goal metrics Leverage a simple approach from the GQM methodology 1.Identify and prioritize goals 2. Question each goal: If we were making progress toward this goal, how would we know? What would change in the business as a result of reaching this goal? 3.Use answers to these questions to identify metrics for goals Metrics help quantify ROI Metrics helps justify ongoing development expense The desire to track metrics often generate important product features

41 © Jeff Patton, All rights reserved, 41 Good business objectives help validate prospective solutions A good set of business objectives help us validate the solutions we choose to construct A good set of business objectives are: short: a single page or slide prioritized measurable

42 © Jeff Patton, All rights reserved, 42 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

43 © Jeff Patton, All rights reserved, 43 Common models such as actors, roles, profiles, & personas describe users Actor & Goal Often a job title or the common name for the type of user in a system User Role Short name describing a user in pursuit of a goal – users change roles as their goals change User Profile Adding summary information about the types of users who fill a role or perform as an actor begins a process of profiling Persona Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target On-line Shopper: browse and purchase merchandise on line Customer Support Rep: aid customers over the phone and on line with issues

44 © Jeff Patton, All rights reserved, 44 Common models such as actors, roles, profiles, & personas describe users Actor & Goal Often a job title or the common name for the type of user in a system User Role Short name describing a user in pursuit of a goal – users change roles as their goals change User Profile Adding summary information about the types of users who fill a role or perform as an actor begins a process of profiling Persona Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target Casual Browser: pass time by browsing products online Comparison Shopper: compare price and features for items I wish to buy Gift Shopper: find a gift for someone that likes the types of products this website sells Impatient Buyer: find what I need and get through the checkout process quickly

45 © Jeff Patton, All rights reserved, 45 Common models such as actors, roles, profiles, & personas describe users Actor & Goal Often a job title or the common name for the type of user in a system User Role Short name describing a user in pursuit of a goal – users change roles as their goals change User Profile Adding summary information about the types of users who fill a role or perform as an actor begins a process of profiling Persona Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target Web Shoppers Users: 50,000 customer visit this sporting goods website monthly Activities: browsing, price comparing, gift shopping, handling returns Computer Skills: vary wildly from first time users to expert – although moderate computer skills are typical Domain expertise: typical customers are avid outdoor enthusiasts…

46 © Jeff Patton, All rights reserved, 46 Common models such as actors, roles, profiles, & personas describe users Actor & Goal Often a job title or the common name for the type of user in a system User Role Short name describing a user in pursuit of a goal – users change roles as their goals change User Profile Adding summary information about the types of users who fill a role or perform as an actor begins a process of profiling Persona Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new equipment releases on the market, and to make sure he has the best equipment he can afford. Hes used computers for years and considers himself an expert user. He maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff hes tried out. Steve Powell competitive mountain biker Im looking for stuff thatll help me stay ahead of the pack

47 © Jeff Patton, All rights reserved, 47 software Software products support a variety of users and their goals. tasks features goals

48 © Jeff Patton, All rights reserved, 48 software In organizations where users are paid to use the software, user goals are driven by business goals tasks features goals All these goals mean lots of tasks, and lots of potential features in our software

49 © Jeff Patton, All rights reserved, 49 Design imperatives describe good characteristics the software should have based on the user type Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. Document these as design imperatives. Think about: ease of learning retention of learning efficiency of interaction reliability of interaction user satisfaction user convenience necessity for proficiency importance of accuracy

50 © Jeff Patton, All rights reserved, 50 A good user model helps us identify functional scope and necessary characteristics of the software A good user model helps: identify functional scope identify necessary characteristics of the software stakeholders understand and empathize with target users validate proposed software solutions An effective user model is prioritized to help rule out unnecessary functional scope and design imperatives

51 © Jeff Patton, All rights reserved, 51 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

52 © Jeff Patton, All rights reserved, 52 Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Draw a left to right axis representing time Identify high level activities performed by users of the system and place them above the time axis in the order that seams reasonable Within each activity, organize tasks in the order theyre most likely completed. Theres likely variation in how theyre completed – so arrange them in a typical order. If you had to explain the process to someone, arrange them in the order youd tell the story. Fill in task details such as business rules or possible features that satisfy the tasks below each task. Task 1Task 2Task 3Task 4Task 5 time Activity 1 Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story)

53 © Jeff Patton, All rights reserved, 53 A good User Story as used in Scrum and other Agile approaches describes the use of the system The user story form considered best practice in Scrum references your user model and user goals. As a [type of user ] I want to [perform some task ] so that I can[achieve some goal ] As aharried shopper I want to locate a CD in the store so that I canpurchase it quickly, leave, and continue with my day.

54 © Jeff Patton, All rights reserved, 54 user story In practice user stories may be written to describe user tasks or the tools that support them software tasks features goals As aharried shopper I want to locate a specific CD in the store As aharried shopper I want to enter a CD title into the search box and initiate a product search More task-centric: More tool-centric: start with task-centric user stories early in product discussion and modeling fill in feature-centric stories till later

55 © Jeff Patton, All rights reserved, 55 Building a workflow model helps facilitate discussion – but requires a bit of space

56 © Jeff Patton, All rights reserved, 56 Workflow or a reasonable sized system can fill a room

57 © Jeff Patton, All rights reserved, 57 Discussions in front of workflow models are more productive

58 © Jeff Patton, All rights reserved, 58 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

59 © Jeff Patton, All rights reserved, 59 Build paper prototypes from repositionable components

60 © Jeff Patton, All rights reserved, 60 Test paper prototypes to determine if theyre usable

61 © Jeff Patton, All rights reserved, 61 Finished prototypes are pieced together from moveable and removable paper components

62 © Jeff Patton, All rights reserved, 62 Build navigation maps and storyboards to communicate UI design

63 © Jeff Patton, All rights reserved, 63 Lets look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping

64 © Jeff Patton, All rights reserved, 64 Prioritize task details by necessity to help visualize layers of functionality across the business process Draw a vertical axis to represent necessity Task 1Task 2Task 3Task 4Task 5 time Activity 1 Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) necessity

65 © Jeff Patton, All rights reserved, 65 Identify releases in spans of coherent functionality Choose coherent groups of features that consider the span of business functionality and user activities. Support all necessary activities with the first release Improve activity support with subsequent releases time optionality necessary less optional more optional activity 1activity 2activity 3activity 4 first release second release third release

66 © Jeff Patton, All rights reserved, 66 Distill your release plan into a roadmap 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. A roadmap serves to clearly communicate release level objectives to stakeholders For each incremental release: Give the release a name or simple statement describing its purpose Write a short sentence or two describing what value the business gets from the release Write a short sentence or two describing what value the users get from the release

67 © Jeff Patton, All rights reserved, 67 Bucketing groups of major functionality or areas of task support is sometimes easier than feature by feature prioritization

68 68 Where to do all those practices fit in a typical Scrum lifecycle?

69 © Jeff Patton, All rights reserved, 69 The simple Scrum snowman process model

70 70 But, its commonly understood the snowman is missing a couple balls… Or, that it takes a taller snowman to model product concerns

71

72

73

74

75

76 © Jeff Patton, All rights reserved, 76 Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another design & plan evaluate build Product Owner Team Composition Business Analysts Interaction Designers Prototypers Responsibilities Gather customer input for features to be implemented in later iterations Design next iteration features Be available to answer questions on current iteration development Test features implemented in the previous iteration Development team Composition Smaller number of seasoned developers UI development skills & analysis skills Responsibilities Implement features for current iteration Collaborate with Product Owner team to acquire details to construct software

77 © Jeff Patton, All rights reserved, 77 Product Owner Team Development Team Design and Coded Features Pass Back and Forth Between Tracks implement iteration 1 features gather user input for iteration 3 features design iteration 2 features support iteration 1 development implement iteration 2 features fix iteration 1 bugs if any gather user input for iteration 4 features design iteration 3 features support iteration 2 development validate iteration 1 features implement iteration 3 features fix iteration 2 bugs if any gather user input for iteration 5 features design iteration 4 features support iteration 3 development validate iteration 2 features planning data gathering design for iteration 1 features – high technical requirements, low user requirements development environment setup architectural spikes Sprint 0Sprint 1Sprint 2Sprint 3 feature design coded features time feature design + bugs found in usability testing

78 © Jeff Patton, All rights reserved, 78 The product owner team steers development The product owner team must: Understand layers of dependent decisions that lead to stories in a backlog Identify stories to meet release level business objectives Defer decomposing and detailing stories until necessary Re-prioritize and create new stories to allow business objectives to be met within time and budget constraints Business objectives and user objectives are targets – user stories are the tools that help you reach them

79 The Scrum Product Owner Practice Surviving the Agile rollercoaster as part of a product owner team Jeff Patton AgileProductDesign.com


Download ppt "The Scrum Product Owner Practice Surviving the Agile rollercoaster as part of a product owner team Jeff Patton AgileProductDesign.com."

Similar presentations


Ads by Google