Techniques for User Story Definition and Sizing

Transcription

1 Scrum Requirements Techniques for User Story Definition and Sizing Victoria Hall Sr. SW Engineering Manager Bio-Rad Laboratories

2 About Me Software development & management Agile background, CSM, CSP, internal coaching Released numerous multi-tiered web and enterprise systems, concentrated in last ten years on bioinformatics and biological sciences External Scrum educator and consultant but I am not writing a book

3 About Me What I m not A Product Owner But, I ve played one I mentored numerous product owners who are new OR young OR water fall-ish OR ALL OF THE ABOVE And taught them about Agile and Scrum and their roles and duties.

4 Why this talk I expect most of us have struggled with developing stories that are: Meaningful Right sized Right described for the planning stage that we are at. Let s share our experiences and discuss some new ideas.

5 About you How many Product Owners here? How many Scrum masters? Any other roles? What size teams? How many years experience? Any questions I should keep in mind as I go through the talk that people have been burning to have answered?

6 T O P I C S Introduction to User Stories Right Sizing User Stories The Last Responsible Moment Estimation Velocity Defining User Stories Micro-planning discussion Closing

7 Introducing User Stories Intro to User Stories Why user stories? What does a user story look like? Generating User Stories

8 Why User Stories? Software is about translating ideas into reality What possible ways can we communicate ideas?

9 Skywriting.

10 Others? Written Verbal Music Multi-media Video

11 Why User Stories? Written communications Provide a permanent record Can be more easily shared with groups and remote personnel Can be well thought out and thorough Can be easily misinterpreted Verbal communications Immediate feedback Dynamic Easily adapts to new developments May spark new ideas Easier to reach common understanding and clarity

12 Why User Stories? User stories combine the strengths of BOTH written and verbal communications Provide some documentation but more important to encourage discussion. Foster interaction Easy to right size Independent Facilitate planning and implementation Gets customer bought into the process and the product Encourages deferring of detail Works for iterative development

13 What is a User Story? What kinds of things do your teams typical User Stories contain? A statement of what value a user will get from using your software A listing of alternative paths related to the initial story Acceptance criteria Possible exceptional conditions and responses that the user should experience An owner An estimate A section to capture any discussion & decisions made

14 An example Consider a source control system Possible user story As a developer, I d like to examine the differences between my development tree and the main repository in order to evaluate what integration issues I need to consider. Acceptance criteria The user interface displays a report of the format below (see picture) that shows the differences between my tree and the main tree. Exceptional criteria If the main repository is unavailable, the developer should see a message that says, The repository server is unavailable. Please correct the problem and try again.

15 Use Pictures Picture of potential UI Keys called out below! List of file differences Summary listing Icons showing different states

16 Limitations paths An example The developer does not have to indicate which tree is theirs only the default developer tree will be evaluated. The report does not have to be navigable at this time. Alternatives none. Owner Ms. Product Owner Estimate 80 team points Discussion Eventually the developer should be able to indicate any tree for comparison with the main repository. This will be deferred to a future User Story. The layout suggested is only a starting point, please let me know what is possible given everything else we ve got going on.

17 What is a User Story? More formally A User Story has three elements It answers the questions Who?, what? and why? It takes the form of As a [user role] I want to [do something in the software] so that I can [statement of value]. Example: As a clinical biologist I want to discover biomarkers so that I can develop a clinical diagnostic for sepsis. As a real estate agent I want to post a notice for a house that I have for sale in order to allow potential buyers to look at it.

18 Generating User Stories? How do your teams generate user stories? User Stories are written and owned by the customer. Ideally this is an actual user or users of the software More practically it is a user proxy Product manager Business analyst Development management Some proxies are better than others why?

19 Generating User Stories? If you end up with a committee of users or user proxies, what do you do? What if your user is inexperienced in software development and requirements generation? Training Collaboration w/ development usu. Scrum master Investment is important

20 Generating User Stories? Other techniques Sales Technical support User surveys User group meetings Customer visits and observations These can help but are no substitute for an actual person to collaborate with.

21 Right Sizing User Stories You have your product owner you may even have a pile of stories Now what? It s really important to right size stories given the stage of planning. How much information is too much? How much is too little?

22 Let the horizon be your guide 6-12 mos Vision Time until implementation 3-6 mos 2-4 weeks Epics Stories Tasks granularity

23 The Last Responsible Moment Requirements churn is bad What is meant by the last responsible moment? Make decisions at the last responsible moment - the point at which failing to make the decision eliminates an alternative. Knowledge of the lead times required for realizing design alternatives is necessary in order to determine last responsible moments

24 Say you re a penguin being chased by a seal. An Extreme Example

25 Time Boxing Decisions A military officer who was about to retire once said: The most important thing I did in my career was to teach young leaders that whenever they saw a threat, their first job was to determine the time box for their response. Their second job was to hold off making a decision until the end of the time box, so that they could make it based on the best possible data. An introduction to Lean Software Development by Mary Poppendieck Interviewed by Gustaf Brandberg Copyright 2004 by Citerus AB, Sweden ( This work is licensed under the Creative Commons Attribution License 2.0 (

26 How to right size? In order to right size you need to accurately assess your planning horizon you need to know how large a story is and to know how much your team can get done in a period of time. The former is estimating the latter is velocity.

27 Estimating Estimating User Stories Story points Estimating techniques Velocity Epics, releases, iterations and tasks

28 Estimating How do you define story points on your teams? A measure of complexity and size of a feature or features relative to others FOR YOUR TEAM Can be Ideal programmer days or hours A totally unrelated to time measure (e.g. agile points, liters, happy days)

29 Estimating They must be Consistent for your team assuming your team is constant Understood by your team Able to be scaled discretely relative to the actual size and complexity of the tasks, stories, epics your team will be estimating They do not scale with who s on the team or the tools they may choose. Or do they??

30 Taking inventory of your library Estimating example

31 Estimating Techniques Estimates are derived by the team collaboratively why? To build consensus To build ownership To add information To add accuracy What ways do your teams estimate and reach consensus about those estimates? Triangulation Fist of five Polling

32 Estimating Techniques - Triangulation Even when you know nothing you know something Is this story bigger than X? Is this story smaller than Y? What are peoples best guesses on size? Can we reach a consensus? Do we have a history of performance on similar sized and complex features?

33 Estimating techniques Polling (aka planning poker) What is consensus? I can live with and support that. Each team member writes down (or holds up) what they think the story will take independently. Estimates are revealed High and Low estimates are defended. New information is likely revealed. User story is adjusted. Re-vote and repeat until consensus is reached

34 Estimating techniques fist of five An estimate is developed somehow and posted for the given story The teams votes on the estimate (1-5) 1 is I strongly disagree 5 is I strongly agree 1 s and 2 s explain their positions, we adjust the user story or share new information and we vote again. Once everyone gets to 3 or more we declare that we have a valid supported estimate.

35 Estimating Techniques A example from the financial world As a financial analyst, I want to predict consumer loan performance for the next year in order to decide how much reserve I must safely maintain to cover defaults. As a financial analyst, I want to capture a single geographic market s labor data as published by the region s Labor Dept (e.g. Total non-farm payroll from the US Bureau of Labor Statistics) so it can be used in future time based analysis. As a financial analyst, I want to capture multiple regions economic data for the last ten years in order to train the analytics engine that predicts consumer loan performance.

36 Estimating Techniques We would all agree The first one is too big to be accomplished in one iteration even with the best and brightest team. It is simply too complex. The second one can be accomplished probably by one person in something less than an iteration provided infrastructure is in place The third one may be a good 1-2 iteration goal. If it s more than an iteration, considering breaking it down even further.

37 Velocity Velocity The measure of how much your team can accomplish in an iteration It takes the form of Story points / iteration Iteration usually equals 1 Story points are only story points actually completed not partially completed This is the bit that should change depending on who s on the team and what tools they use.

38 Velocity Velocity is an unknown with A new team A new project Any time someone comes onto team or is re-assigned off of the team Educated guesses are fine initially Or Run a sizing iteration whose main purpose is to help the team get a measure of its velocity in order to better plan future iterations. Especially helpful in contract work if it can be arranged. Eventually your team will understand how much they can accomplish in an iteration and how that relates to whatever pointing system they are using.

39 Velocity How do you measure velocity? Why do we only count stories actually completed in the velocity? How would we measure a fractionally completed story? Most importantly if something is not complete it usually cannot be used therefore may not be of value to the end user or business. It doesn t count if it s not DONE. If stories are routinely partially completed, they are probably too big for your team.

40 Sizing For The Horizon Depending on where we are in the planning process the size of user stories must be different. Remember velocity helps us determine the appropriate planning horizon and estimates give us a way to determine whether we are discussing things in the proper granularity.

41 Sizing For The Horizon Epic Stories these are your largish user stories. Are written whenever discovered but are usually tackled within a release time frame. This is typically 3-6 mos. This may be different for your team They are often aggregate user stories that are compounded or of sufficient complexity that they must be broken down.

42 Sizing For The Horizon User Stories this is the most commonly sized user story Again, they can be written whenever discovered but contain only enough detail to be a place holder if they are scheduled for later iterations. As they are scheduled for nearer iterations, the level of detail should increase. If they are scheduled for this iteration, they need to have enough detail to begin implementation discussions. Time horizon 2-4weeks Tasks this is where a user story ends up once it s been slotted for an iteration and needs to be implemented. Time horizon hours - 2 days

43 It s all relative.

44 Good User Stories G.U.S.

45 Good User Stories (GUS) How do you tell if a user story is GOOD? Describe what users DO in easy to understand language Instigates discussion Take a slice through the whole system Represent acts that can be completed Capture constraints and limitations Explicitly state dependencies, if known Are written by the customer Can be estimated; can be validated

46 Good User Stories What do you want to do today? Choose stories that describe something that your users will ACCOMPLISH with your software List these for each user role for your software These may be large at first E.g. Locate the perfect home for my family or Edit a movie Consider these as starting points if they are too big, break them down

47 Good User Stories Take a slice through the system. If a story is too big, break it down on natural system boundaries. Do a less complex but useful version first A real estate agent can submit a home that includes only geographic area and property number. A movie editor can identify and save key frames. It is functionality that touches all parts of the system but can be done in an iteration.

48 Good User Stories Write closed stories- stories that end with the achievement of a meaningful goal. 1 Instead of a home seeker can maintain her search criteria. A home seeker can create her search criteria A home seeker can review the results from a search. A home seeker can change the geographic area for her search criteria. 1. Cohn, Mike User Stories Applied Pearson Education

49 Good User Stories What a system should not do is as important as what it should do. Write down constraints and limitations such as Technology Dependencies Performance Platforms Tools Whatever else you can think of that matters

50 Good User Stories Good user stories are written by the customer What if they won t or can t? Help them to do it Write stories that are dictated Suggest stories if they are stuck Collaborate on new stories if they can t decide If you help, don t do it for them. As much as possible, get them to be involved and owning what the software is supposed to accomplish Teach, mentor, coach.

51 Bad User Stories B.U.S. How do you tell if you have a bad user story?

52 BUS Indicators Platinum plating Too small Too big Interdependent Including the UI too soon Thinking too far ahead. Classic! When stories become tasky see too small Customer can t prioritize Too many details to fit on a card or card proxy

53 BUS Mitigation Platinum plating The user story is A biologist can view the instrument data in a landscape plot that is scrollable and scalable. The platinum plating would be A biologist can view the instrument data in a plot whose aspect is configurable that is scrollable and scalable and zoomable and may change color. We want to give users more than they ask for. Resist the urge. It takes time to implement, test and document things that the user didn t ask for and may not need.

54 Breaking things down How do we know a story is too big? Not estimated to fit in one iteration. Team is repeatedly moving partial stories out of an iteration into the next one. What do we do about it? Break stories down. This also applies to place holder stories once you get to planning.

55 Breaking things down Techniques for dividing up a user story that is too large Disaggregate along data boundaries

56 Breaking it down Other techniques Break complexity down by time boxed phases Investigate Implement Break a story down into its compound elements Creation, editing, removal, maintenance as a combination of all three Insert, update, delete from the database side of things

57 Building it up How do you know if you have a story that s too small? Usually it s finished in a very short amount of time. It s too simple to be useful by itself Your team finds that it s forgotten lots of important things that contribute to done-ness

58 Building it up If a story is less than a ½ day of work, consider combining it with another related story. Don t forget the little things these may be ongoing maintenance kinds of things Defect fixing Documentation Regression test updates User interface tweaks They all take time and should be planned for.

59 Creating Independence If a user story depends on too many other user stories being completed, it is not independent enough. Does anyone have a good rule of thumb for too many dependencies? What do you do about it? Maybe you need a hierarchy and not a chain (or web) of dependencies? It may need to get bigger. It may need to get smaller.

60

61 Micro-planning If short iterations are good, are shorter iterations better? Software development can be thought of as a series of analyze-code-build-test cycles. Every large section of software will pass through this cycle (many times), but so will every small section of code. A developer may go through these steps several times a day, or even, many times per hour If a requirement is not being used, it is in process inventory This is waste. The idea of continuous flow and the least responsible moment fit nicely. Can we do better than traditional SCRUM?

62 Increase Utilization If we look at reduction in cycle time relative to utilization and assume that high utilization is good. Mary and Tom Poppendiek

63 Reducing Cycle Time Queuing theory gives us six rules for reducing software development cycle time: 1. Limit work to capacity 2. Even out the arrival of work 3. Minimize the number of Things-in-Process 4. Minimize the size of the Things-in-Process 5. Establish a regular cadence 6. Use pull scheduling

64 For your consideration So if you want high utilization and low cycle time, you should develop in very small batches. For example, you will get much faster throughput and higher utilization if you develop ten services one at a time, rather than developing all ten at the same time. Can we develop in 1 day iterations? What would the user stories look like? What are the challenges?

65 Closing Introduction to User Stories What is a User Story The Last Responsible Moment Developing User Stories Right Sizing User Stories Micro-planning Have we answered all the questions?