AGILE REQUIREMENTS. in 60 minutes LOOP CHASER GO&DO! AGILE REQUIREMENTS. Fun! Educational! Lean! used and still being agile?

Transcription

1 AGILE REQUIREMENTS in 60 minutes Introducing the Loop Approach Fun! Educational! Lean! AGILE REQUIREMENTS How on earth can all this be used and still being agile? AGILE REQUIREMENTS LOOP CHASER GO&DO! 18+ Raedy Steady Go!

2 ROASTING IMPACT MAPPING WIRE FRAME STORY BOARDING STORY WRITING PERSONAS INTRODUCTION WHY THIS BOOK? The number one agile principle is to satisfy the customer with frequent deliveries. The shorter time-box, the faster feedback-loop and the more opportunities for adaptation and adjustment. The process starts with requirements gathering and ends with its Siamese twin, i.e. acceptance testing. As Agile coaches we have experienced how one can accelerate this process by mixing various requirement and testing methods and being sure to avoid duplication. We like to analyze a demand from different perspectives to intensify learning and spare unnecessary work until the last responsible moment. 2 Adopting collaboration and just-in-time requirements is the key to become agile. The intent of the agile requirement molecule, user stories, is to foster collaboration; the perspective is on customer value. This book is the second of a series and it is a more detailed continuation of our first book, agile inception, which describes how to combine methods to define and narrow down an initiative. We are happy if this book make you FAIL (First Attempt In Learning). Questions and feedback are welcome! 3

3 INTRODUCING THE LOOP APPROACH This book is about mixing methods for efficient release planning. Release planning is mentioned in Scrum and an essential part of Extreme Programming and other ancestors. We have noticed an increased interest in this subject, probably because of the agile transformation that haunts traditional organizations these days. Practicing agile has taught us how a structured method in the hands of a cross-functional team accelerate throughput multiple times. We use this same approach for release planning; to identify features, split them into tangible user stories, mapping stories into an overview, and finally, from that story map, slice out the most valuable release. Här skulle man kunna ha en fyllig innehålsförteckning, så får man en sammanfattning av de olika metoderna som tas upp också! Discussions around requirements (and testing) tend to be a very complicated tangle of methods, buzz words and perspectives; features, use cases, scenarios, activity diagram, process map, epics, user stories, story board, wireframe, customer journey, story map, product backlog, themes, release plan, iteration plan, business-, user-, software, solution requirements, behavioral driven development, acceptance test driven development, specification by example you name it! And more to the point how on earth can all this be used and still being agile? Introducing the Loop Approach in the following pages we share our experiences of method blends under different circumstances. This is, however not a cook book describing exactly how you should work, our aim is to give you inspiration, and we should not deny also some hallelujah moments. It all boils down to: Ready-Steady-Go GO! Go & Do! Go & Do! Part 4 All you need to know about requirements but were afraid to ask Further readings & acknowledgements? 4 5

4 BUCKETING USE-CASE MODELING PERSONAS FINAL RELEASE PLANNING PRODUCT VISION FUTURE LISTING PLANNING POKER STORY MAP VALIDATION LOOP 1: READY, STEADY, GO Theme: process-driven work along a customer service model mode a.k.a. service design STORY MAPPING Background Complex delivery chain; multiple touch points (and channels), multiple system integrations with dependencies, multiple services delivered by third parties, and multiple support roles. Preconditions: A predetermined customer lifecycle model Example of fit: As a large organization delivering products/ services via customer lifecycle processes I want a faster and disciplined release planning So that I can make better investment decisions 6 Acceptance Criteria: Verify that you have a validated product vision Verify that the customer lifecycle is the foundation for feature identification Verify that features are decomposed into use case diagrams Verify that your customer segment have been validated with personas Verify that your prioritized high-level stories have been identified for further decomposition. Verify that your final release plan covers both smaller, testable user stories for initial iteration and high-level stories for upcoming iterations Verify that the release plan can be used for initial cost and time estimates Time box: 10 working days 7

5 PRODUCT VISION We collaborate in smaller teams, 3-4 individuals, to ease cooperation and to get multiple alternatives before narrowing them down and merging into one end-result. Elevator Pitch sentence structure: FOR (target customer) (customer need),, WHO HAS (product name) Elevator pitch example: FOR a multi-site vpn customer, WHO HAS a need for movable high-speed access point, MovIT IS A virtual private network service THAT provides 4G access with quick launch and backup capabilities UNLIKE competing vpn services MovIT has one contract, one bill and one help desk The elevator pitch gives us an initial understanding; for whom, we should do what and why. IS A (one key benefit) (market category) UNLIKE THAT (competition) Source Product Vision Feature Listing Use-case diagram User persona THE PRODUCT (unique differentiator) Who Customer segment User role Persona User role What Product Feature title description The elevator pitch sentence structure is written on white board, or flip chart, with breaks for the keywords, e.g., target customer. Key benefit & Unique differentiator Goal Goal The key words are written on post-it notes to ease duplication and replacement. The exercise runs in time boxes of minutes, each ending with a demo. We show each other to generate new ideas. Let s continue to look for features along our customer life cycle model. The last time box is focused on narrowing down alternatives into one end-result. We use dot-voting to facilitate collaborative decision making. 8 9

6 FEATURE LISTING - It is a brilliant product but their payment service sucks. An innovative payment capability can attract customers more than adding product features. A customer life cycle model describes customer and product interactions. It is used as a foundation to make sure customers are satisfied every time they are in touch with the product. 1. Sketch life cycle stages on a white board, or flip chart, in their order of appearance. 2. Identify wanted features and write them on post-it notes, e.g. Find product via web. 3. Use color-coded post-it notes to distinguish between channels (web/ newsletter) e.g., Find product via web and Find product via newsletter 4. Stick the post-it notes to their related life cycle stage. Still on a high-level we have expanded our what, only briefly described in the elevator pitch, to a set of features needed for a complete customer experience. Source Who Product Vision Customer segment Feature Listing What Product Feature Key benefit & Unique differentiator Use-case diagram User persona User role Persona User role title Goal description Goal Let s move on and decompose these high-level features. We are still going for breath-before-depth and stay away from the details. Find Choose Pay Use End Find products via web Find products via newsletter Pay by creditcard Pay with online payment service 10 11

7 USE-CASE MODELING Service design is complex; it combines parallel development of both product and process, i.e., system integrations and supporting roles, to cope with this complexity, we break down each customer life cycle stage into its own use case diagram. A use case diagram describes user interaction with a product. An oval represents a use case which is connected to a user role (straw man) with a line. 1. Put identified features at the top of flip chart, e.g., Pay by credit card. 2. Start to identify user roles. Which customers are on this customer life cycle stage? Which customers could be? What systems, services or support roles do we need integration with or get help from? 3. Name user roles with singular domain-relevant nouns. Write them on post-it notes and stick them to the flipchart. Straw man is optional. Shop Online View Products Payment Processing System 4. We continue by identifying the use-case needed by the user roles. does a customer use the product? would the payment processor system have an interface with us? Online Customer Purchase Products Manage Customer information Fulfil Order 5. Begin use case titles with a strong verb from the domain terminology. Write down identified user story titles on post-it notes, e.g. Search for items Stick them to the flip chart and draw line connections to user roles Oval is optional. Compare Products Manage Product Report inventory Warehouse Clerk Find Choose Pay Use End Find products via web xxx Pay by creditcard xxxx xx xxxxx Marketing Administrator Report Product Sales Manage inventory Warehouse Manager Use Case Model Use Case Model Use Case Model Use Case Model Use Case Model The actual users of the product are on the left hand side, whereas system integrations and support roles are shown on the right hand side. The primary user role is placed in the top-left corner of the diagram. We increase the readability of the use case diagrams by arranging use-cases to imply timing

8 Remember to make one use case diagram each per identified channel e.g., Find product via newsletter and Pay by online payment service Find products via newsletter Pay with online payment service PERSONAS A persona is an archetypal description of a fictional person s characteristics, demographics and goals. Tip - make 2-4 sketchy personas illustrating the top three characteristics, demographics and goals of our primary customers. Once again, post-it is king. Use Case Model Use Case Model Photo Each high-level feature is decomposed into 5-10 user stories. Our understanding of what and whom has increased quite a bit. Source Who Product Vision Customer segment Feature Listing What Product Feature Use-case diagram User persona User role Persona User role title description MOI? Name Description Age What does the person do? The persons goal? What does the person do? The persons goal? What does the person do? The persons goal? Key benefit & Unique differentiator Goal Goal We need to find out more about whom we are dealing with, let s zoom in on our customer segment. The personas add customer understanding. We are especially interested in their goals, which we use to validate our current use case diagrams. 1. Did we learn something new from the personas? 2. Do we need to adjust some of our use case diagrams? 14 15

9 XLARGE XLARGE Tip personas can later be used for UX trade-offs decisions as well as global conditions and constraints prioritization. Our first complete break down cycle have come to an end, we have achieved a foundation for why we are planning to do what and for whom. Source Who Product Vision Customer segment Feature Listing What Product Feature Key benefit & Unique differentiator Use-case diagram User persona User role Persona User role title Goal description Goal BUCKETING Estimation is based on a combination of experience and guessing. It is never correct and from a lean perspective a kind of waste. Still, we need to estimate expected effort in order to be able to prioritize and plan upcoming work. We use bucketing in combination with T- shirt sizes to be quick and don t waste too much time. 1. Make a swim lane wall with T-shirt sizes at the top, starting from XS, S, M, L, XL. 2. Choose a reference story to compare everyone else against. A common strategy is to choose the smallest one and declare it to be of XS size. 3. Stick user stories to corresponding swim lane. 4. Mark each user stories with its size estimate, e.g. S. Let s make some estimation, prioritization, calculation and planning before we continue with further decomposition and detailing. LARGE SMALL MEDIUM LARGE XXLARGE 16 17

10 RELEASE PLANNING (INITIAL) Initial release planning is aimed to give us a rough idea of what s required to deliver a complete customer experience. We will also learn where to put our focus, i.e. the stories prioritized for 1st release. Stories are prioritized by weighing their business value against estimated implementation effort. 1. Make another swim lane wall with 1st, 2nd and Later at the top of the lanes. 2. Stick the most important user stories to the 1st release lane. STORY SPLITTING The initial estimation figures make a good starting point for further story splitting. As a rule of thumb, all stories above XS size need further decomposing. The general guidance favor vertical slices before horizontal slices, e.g. splitting stories across all architectural layers. Having said that, there are loads of guidelines out there, however practical experience is really what counts do not be afraid of making mistakes learning by doing will make, you fail, but also succeed after some training. 3. Stick next priority stories to the 2nd release lane. 4. Stick the rest of the stories to the later lane (= backlog) 5. Mark stories prioritized for 1st release. Workflow or CRUD Bucketing Release Plan XS S M L XL 1st 2nd Later Data type of parameter? or Interface variation Business rule or Defer performance Effort variation Most user stories are still vague and too big to fit within iteration. They must be split and detailed with descriptions, acceptance criteria and additional information Breach out a spike The INVEST model can serve as a high-level definition of ready: Independent. Reduced dependencies = easier to plan Negotiable. Details added via collaboration Valuable. Provides value to the customer Estimable. Too big or too vague = not estimable Small. Can be done in less than a week by the team Testable. Good acceptance criteria and test case 18 19

11 STORY WRITING A user story is written from a user-centric perspective and it describes: who want what and why The user story title works as a short summary. Title Title As a I want n online customer So that to pay my order by credit card I avoid the risk of losing money Pay by credit card As a I want So that (user role) (some capability) (some goal) The format above is only half the story; a complete story contains significantly more information, where the most important is the acceptance criteria. Though it s hard to pick acceptance criteria out of the air, we need a better, methodical approach. An acceptance test case, written in Behavioral Driven Development format, describes an implemented user story s expected behaviors. It matches perfectly with the user story technique and if test data are included it makes the outcomes crystal clear. Given some initial context (the givens) And to connect multiple givens When an event occurs Then ensure some outcomes And to connect multiple outcomes User stories were initially written, processed and kept on index cards. Nowadays, user stories are managed and stored electronically, but a workshop is much better off using index cards, or post-it notes, to make everyone attending deeply involved in the process and being able to contribute in an easy way. The goal is to get everyone writing stories - and learn that it is great fun We turn identified user story titles into user stories simply by adding a description in accordance with the format above telling who, wants what and why. NOTE: A user story is an invitation to a conversation, meaning that an initial user story description must be discussed and processed from business, test and coding perspectives, many times, before the story is ready for implementation. Tip Use traditional test cases if you are more familiar with that technique. What matters is to capture the outcomes. 2. We start to talk about how we are going to demo the implemented user story and write a test case/scenario (happy path), where the expected outcomes fall out as an acceptance criteria. 3. Then, we discuss if there are any alternate paths to be demoed and what their expected outcomes are. These are our next set of acceptance criteria. 4. When we talk about test cases we realize that the initial user story needs further clarification or perhaps needs to be split into two user stories. Clarification often leads to yet other acceptance criteria. 5. We also get ideas on how the implementation should be done. Implementation details usually add acceptance criteria. 21

12 6. Finally we discuss whether there are any conditions or constraints that the specific user story must meet e.g. performance criteria or business rules. These become acceptance criteria and test cases as well. 7. The identified acceptance criteria, acceptance test cases and additional information is written down, either on the back of index card or else on additional post-it notes. STORY MAPPING Customer journey style Story mapping is process prototyping for simulation and validation of a complete user experience. You should be able to read a narrative of your service by walking through the user stories, one after another, following the customer life cycle backbone NOTE: Experience mapping (as-is) or customer journey mapping (to-be) used in the service design domain are equivalents to story mapping. What Ace Test As our example relies on a customer life cycle, we make our story map in customer journey style; customer life cycle stages, user stories and user roles are organized into a structured map. 1. Arrange customer life cycle stages from left to right in time sequence order. Acc Crit. + Conditions Constraint 3. Make separate swim lanes for each user role. 2. Make separate swim lanes for each channel. NOTE: Customer role(s) are described by persona(s). Bring them here. Our user story conversation not only help us capture acceptance criteria, specific conditions, constraints and omissions are also discovered, but most important, our on-going conversation have validated the user stories. All participants have much more understanding of the service than they ever can achieve by reading produced documentation. We split into smaller team fractions, responsible for one life cycle stage each, to ease collaboration, and merge our outputs into one big map. 4. Organize user stories in happy paths and alternate paths beneath each life cycle stage, and in correct swim line(s). Source Product Vision Feature Listing Use-case diagram User persona NOTE: By organizing those stories, we just made multiple use cases, scenarios or process maps, whatever you call them. Method terminology shouldn t be such a hurdle. Who Customer segment User role Persona User role 5. Finally, discuss and capture driving global conditions and constraints What Product Feature title description User persona User persona User persona Feature Feature Feature Key benefit & Unique differentiator Goal Goal Story splitting and writing have generated a number of detailed user stories, how do we get things sorted again? Will this service really fly? Do we miss something important? 22 23

13 STORY MAP VALIDATION We take a step back and look at the complete picture again and simulating use of the service. Frankly, we are looking for omissions; 1. Is there anything that is missing or looks strange? 2 2. Should we change the workflow order? 3. Does that user role really need that feature? 40 User persona User persona User persona Feature Feature Feature X X X X X X X Workflow PLANNING POKER X X X Splitting user stories make us re- estimate before final prioritization. As we approach implementation, conversation among team is valued higher than being fast. So this time we estimate by means of planning poker. It takes a little longer, but this effort will pay off at iteration planning. X = Prioritize After a few simulation cycles, including changes and adjustments, we all agree that; THIS IS IT!! 1. Run planning poker Each team member gets a set of cards. A meeting moderator selects a work package or a user story to estimate. He who know best what is estimated describing the The team discusses and asks questions to get a better understanding of what is to be estimated Each team member makes its own estimates by selicting a card without showing the others. All show their cards simultaneously. If the estimates are significant, motiverar those who placed the highest and lowest their choises. The previous two steps until the repteras estimates converge. 2. Mark stories with story points estimates. 3. Remember the INVEST model do another split if required

14 RELEASE PLANNING (FINAL) Final release planning, well not really, just final for 1st release, additional releases will require another go. However, upcoming release planning will start from an established baseline and hence be much quicker, but we should walk through every step of the Loop to make sure we don t miss out anything. 1. Prioritize stories by weighing their business value against estimated implementation effort. A high position indicates they are absolutely necessary, lower position indicate they are of less business value. 2. Draw a line across the stroy map to mark what s included in 1st release. 8. Calculate expected cost based on number of iteration x team cost. 9. Present time and cost estimates as an interval; actual +- risk factor of one/two iterations. STORY SHARING AND STORAGE An agile team working collocated would prefer keeping the release plan, a.k.a. product backlog, in a visualized format but many organizations have policies and standards pointing at templates or tools. Most modern collaboration tools manage user stories, acceptance criteria, test cases, story points, sketches, and release/iteration labels etc. Required documentation can easily be extracted it is just a click away. User Role 1 User Role 2 User Role 3 Epic1 Epic2 Epic3 Story 3(2) Story 5(5) Story 8(1) Story 11(8) Story 17(1) Story 19(2) Story 2(1) Story 6(5) Story 10(2) Story 12(1) Story 16(3) Story 20(2) Story 1(5) Story 4(8) Story 9(8) Story 13(2) Story 15(5) Story 21(3) R2 Story 7(3) Story 14(3) Story 18(5) 3. Mark stories with 1st release. 4. Calculate the total number of story points for 1st release 5. Divide release in iterations based on team velocity (or by guessing if not historic data exist) 6. Calculate expected release date, based on numbers of iteration x iteration length. Add one or two iterations dependent on risk

15 PERSONAS STORY MAPPING STORY MAP VALIDATION RELEASE PLANNING STORY STORY PRIORITIZATION PRIORITIZATION PRODUCT VISION LOOP 2: GO! Theme: map driven work mode Background: Legacy environment with multiple dependencies? Preconditions: Domain model? Example of fit: As an agile development organization I want a user-centric look-ahead plan for multiple releases, aka the user story map So that I get release-based long term planning 28 PLANNING POKER FRACTAL MODELING Acceptance Criteria: Verify that you have a validated product vision Use case modeling Verify that you have a first level of feature decomposition through fractal mapping Verify that you have the user story map backbone with roles and global constraints identified, aka the walking skeleton Verify that your user story map roles are developed into user personas Verify that your have prioritized your immediate next release candidates in your user story map Verify that your release candidates are in a written and estimated user story format with acceptance criteria s and placed in the user story map. Verify that you have a validated release plan in user story format covering prioritized stories and smaller stories as first iteration candidates Timebox: 5 working days USE-CASE MODELING 29

16 TECHNIQUES Product vision Use case modeling Fractal modelling identify stories (title), split (one level) Breath before depth (feature list aka walking skeleton) mapping title, find omissions, test scope, global constraints = product User personas Run prioritization session (continue with user story map) Write user story description acc criteria (local constraints = feature), estimation Additional Story splitting Run validation of user story map Tag release candidates in the user story map Extract data for document WORKSHOPS Fractal model WS mapping WS Story writing estimation WS 1. The elevator pitch sentence structure is written on white board, or flip chart, with breaks for the keywords, e.g., target customer. 2. The key words are written on post-it notes to ease duplication and replacement. 3. The exercise runs in time boxes of minutes, each ending with a demo. We show each other to generate new ideas. 4. The last time box is focused on narrowing down alternatives into one end-result. We use dot-voting to facilitate collaborative decision making. Elevator pitch examples: FOR a caring master, WHO HAS a need to get dog food delivered at home, Mongrel is an online shop THAT provides wholesome dog food UNLIKE competitors THE PRODUCT has weekly or monthly subscription PRODUCT VISION Who s the customer? What s the customer need? What s our product? is the product valuable? An elevator pitch helps us capture and structure our answers to these questions into a self-exploratory vision. We collaborate in smaller teams, 3-4 individuals, to ease cooperation and to get multiple alternatives before narrowing them down and merging into one end-result. Elevator Pitch sentence structure: FOR (target customer), WHO HAS (customer need) IS A (market category), (product name) THAT The elevator pitch gives us an initial understanding; for whom, we should do what and why. Source Who What Product Vision Customer segment Product Key benefit & unique differentiator (one key benefit) THE PRODUCT UNLIKE (competition) (unique differentiator) 30 31

17 Online Customer Marketing Administrator Shop Online View Products Purchase Products Manage Customer information Compare Products Manage Product Report Product Sales Fulfil Order Report inventory Manage inventory Payment Processing System Warehouse Clerk Warehouse Manager gration with or get help from? 3. Name user roles with singular domain-relevant nouns. Write them on post-it notes and stick them to the flipchart. Straw man is optional. 4. We continue by identifying the use-case needed by the user roles. does a customer use the product? would the payment processor system have an interface with us? 5. Begin use case titles with a strong verb from the domain terminology. Write down identified user story titles on post-it notes, e.g. Search for items Stick them to the flip chart and draw line connections to user roles Oval is optional. Let s go and hunt down some initial features, telling us more about what. USE CASE MODELING A use case diagram describes user interaction with a product. We have identified 5-10 high-level features and increased our Source Product Vision Use-case model An oval represents a feature which is connected to a user role (straw man) with a line. Who Customer segment User role The actual users of the product are on the left hand side, whereas system integrations and support roles are shown on the right hand side. What Product title The primary user role is placed in the top-left corner of the diagram. We increase the readability of the use case diagrams by arranging use-cases to imply timing. Key benefit & unique differentiator Just do it: 1. Use blank flip charts, plastic film or a white board for modeling. 2. Start to identify user roles. Which user roles are on this product? Which user roles could be? What systems, services or support roles do we need inte

18 understanding of what capabilities our product need. Let s continue the decomposition using a really fast technique. FRACTAL MODELING Fractal modeling is a decomposition technique for quickly establishing a great number user stories without too much methodology, but still in a structured way. This is the ultimate technique aiming for breadth before depth. 1. Use blank flip charts, plastic film or a white board for modeling. 2. Write the feature on a post-it note, user story title, and stick it to the center. 3. Split the feature using all possible variant of common splitting patterns: Workflow steps or CRUD Data types or parameters Business rules or interface variations 4. Write the next level stories, user story titles, on post-it notes and stick them to the model 5. Draw line connections between adult and children. 6. Perform step 1-4 in cycles, as long as new stories fall out. Source Who What Product Vision Customer segment Product Key benefit & unique differentiator Use-case model User role title Fractal model title The initial 5-10 high-level features have been broken down to more than 50 user story candidates, written as user story titles. We have quickly generated a lot of opportunities based on the initial what, but the questions is; will all of them make it to the part? mapping will help us sort thing out and show us the big picture. The initial features are the backbone a.k.a. walking skeleton and the stories will be attached. Hang on. USER STORY MAPPING A user story map (together with product vision) should tell the whole story of a product. User role, feature and decomposed user stories are organized into a structured model: 1. Arrange user roles in from left to right in priority order 2. Arrange features from left to right in time sequence order (or priority order if sequence is unimportant) 34 35

19 Photo Name Description Age MOI? What does the person do? What does the person do? What does the person do? The persons goal? The persons goal? The persons goal? 3. Draw connections between user roles and features. User roles commonly use more than one feature. 4. Put all decomposed user stories beneath each feature To make sure we are on the right track with whom, let s zoom in on our user roles. Source Product Vision Use-case model Fractal model User Persona USER PERSONAS Who Customer segment User role User role A user persona is an archetypal description of a fictional person s characteristics, demographics and goals. What Product title title Based on the stakeholders in the impact map, we make 2-4 user personas illustrating their top three characteristics, demographics and goals. Once again, post-it is king. Key benefit & unique differentiator Goal A brief word of advice The user personas can also be used for UX tradeoffs decisions as well as global conditions and constraints prioritization

20 The user personas give us a foundation for user roles and we are especially interested in their goals, which might generate additional stories or even require feature updates. Let s go back to the user story board and conduct a prioritization exercise. RUN PRIORITIZATION SESSION (continue with user story map) Nowadays, user stories are managed and stored electronically, but a workshop is much better off using index cards, or post-it notes, to make everyone attending the workshop deeply involved in the process and being able to contribute in an easy way. The goal is to get everyone writing stories - and learn that it is great fun. 1. Prioritize user stories based on their business importance. A high position indicates they are absolutely necessary, lower position indicate they are of less value. 2. Walk through the whole model and look for omissions. 3. Finally, discuss and capture driving global conditions and constraints USER STORY WRITING A user story is written from a user-centric perspective and it describes: Title As a I want n online customer So that to pay my order by credit card I avoid the risk of losing money Pay by credit card who Title As a I want So that want what and why (user role) (some capability) (some goal) The user story title works as a short summary. User stories were initially written, processed and kept on index cards. Let s make this baby rock: 1. We turn identified user story titles into user stories simply by adding a description in accordance with the format above telling who, wants what and why. NOTE: A user story is an invitation to a conversation, means that an initial user story description must be discussed and processed from business, test and coding perspectives, many times, before the story is ready for implementation. The format above is only half the story; a complete story contains significantly more information, where the most important is the acceptance criteria. Though it s hard to pick acceptance criteria out of the air, we need a better, methodical approach. An acceptance test case, written in Behavioral Driven Development format, describes an implemented user story s expected behaviors. It matches perfectly with the user story technique and if test data are included it makes the outcomes crystal clear. Given some initial context( the givens) And to connect multiple givens When an event occurs 38 39

21 Then ensure some outcomes And to connect multiple outcomes A word of advice Use traditional test cases if you are more familiar with that technique. What matters is to capture the outcomes. 2. We start to talk about how we are going to demo the implemented user story and write a test case/scenario (happy path), where the expected outcomes fall out as an acceptance criteria. 3. Then, we discuss if there are any alternate paths to be demoed and what their expected outcomes are. These are our next set of acceptance criteria. 4. When we talk about test cases we realize that the initial user story needs further clarification or perhaps needs to be split into two user stories. Clarification often leads to yet other acceptance criteria. 5. We also get ideas on how the implementation should be done. Implementation details usually add acceptance criteria. 6. Finally we discuss whether there are any conditions or constraints that the specific user story must meet e.g. performance criteria or business rules. These become acceptance criteria and test cases as well. 7. The identified acceptance criteria, acceptance test cases and additional information is written down, either on the back of index card or else on additional post-it notes. 8. Organize stories in accordance with user story board structure, i.e. What Ace Test Acc Crit. + Conditions Constraint place stories beneath corresponding feature. 9. Estimate the effort associated with each story by means of planning poker. See planning poker description on page? 10. Mark stories with story points estimates 40 41

22 11. Prioritize which user stories that add most value or is necessary to do early for technical reasons. 12. Place prioritized stories high on the map. Source Product Vision Use-case model Fractal model User Persona Who Customer segment User role User role User role What Product title title Capability Key benefit & unique differentiator Goal Goal The conversation about our user stories from confirmation/implementation perspectives has not only helped us to capture acceptance criteria, omissions and specific conditions/constraints, but also validated the user stories. A word of advice if an electronic storage format is preferred, do this administrative task after the workshop. As a rule of thumb, all stories above 5 story point size need further decomposition, but before story splitting we spend some time validating what we got so far. STORY SPLITTING The general guidance favor vertical slices before horizontal slices, e.g. splitting at data types rather than workflow. Use this step wise checklist of common splitting patterns to choose splitting technique: 3. Business rules or interface variations 1. Workflow steps or CRUD 2. Data types or parameters 42 43

23 What Ace Test The stories being split, needs to be organized into the user story map, and then we should validate it to ensure the product, and its processes, deliver the desired outcome an delight our customer. VALIDATE THE USER STORY MAP We take a step back and look at the complete picture and simulating the use of the product. We are looking for omissions; 1. Is there anything that is missing or looks strange? Acc Crit. + Conditions Constraint 4. Effort variation or defer performance 5. Break out a spike We recommend; story splitting workflow (page?) for further reading, but practical experience is really what counts - just do it. NOTE: Splitting stories, means splitting test cases, acceptance criteria, and re-do estimates as well. A word of advice - What makes a good split is dependent on iteration length, integration, build and deployment process. Smaller stories are always better but require continuous integration/deployment opportunities at hand 2. Should we change the workflow order? 3. Does that user role really need that feature? 44 45

24 After a few simulation cycles, including changes and adjustments, we all agree that; THIS IS IT!! Let s move on to release planning. RELEASE PLANNING Tag release candidates in the user story map 3. Calculate the total number of story points for 1st release 4. Divide release in iterations based on team velocity (or by guessing if no historical data exist) EXTRACT DATA FOR DOCUMENT An agile team working collocated would be fine keeping the release plan in this visualized format but most organizations have policies and standards pointing at templates or tools. Most modern collaboration tools manage user stories, acceptance criteria, test cases, story points, sketches, and release/iteration labels etc. Required documentation can easily be extracted it is just a click away. We are done with the stories and we need a look-ahead plan before pulling the first stories for implementation. Release planning couldn t be easier: 1. Draw a line across the story board to mark what s included in 1st release. 2. Mark stories with 1st release

25 IMPACT MAPPING ROASTING PERSONAS WIRE FRAME STORY BOARDING STORY DETAILING STORY WRITING LOOP 3: GO & DO! Theme: prototype-driven work mode Preconditions: Collocated team Example of fit: As a cloud and app development organization I want an accelerated and prototype-driven way-of-working So that I get to the minimal product on market with right timing Acceptance Criteria: Verify that you have a prioritized prototype visualized in a story board format Verify that requirement details are provided by user stories in storytelling format for contextualizing purposes Verify that story board and storytelling content are validated with stakeholders external to the team 48 Timebox: 3 working days TECHNIQUES Impact mapping User persona Story board Story writing Roast the story board omission, wrong design (interaction, look and feel, prio/polling Story splitting Story detaling Pull from the story board Extract and write docs 49

26 Who? How? How? What? What? What? Source Who What Impact Map Stakeholders Features? What? Goal Who? How? How? What? What? What? What? To make sure we are on the right track with whom, let s zoom in on our stakeholders. USER PERSONAS A user persona is an archetypal description of a fictional person s characteristics, demographics and goals. IMPACT MAPPING Impact mapping is brilliant for organizing an initiative in a logical structure: Based on the stakeholders in the impact map, we make 2-4 user personas illustrating their top three characteristics, demographics and goals. Once again, post-it is king. 1. First, identify the goal, why is this initiative important? 2. Next step, who are the stakeholders/actors who we need to influence and impact (who can block it or support the goal)? 3. What are the actual impacts we need the actors to engage in as a desired change of behavior in order to progress towards the goal? 4. Finally, what organizational activities and/or software capabilities, in short the deliverables that will facilitate the impacts being achieved? A word of advice - A good practice is to build mind maps and impact maps with stickers on a white board. This format lets everyone in a team participate and it is easy to make changes. MOI? Photo Name Description Age What does the person do? What does the person do? What does the person do? We focus on finding the shortest path through the map in order to execute the goal, a minimal 1st release. The persons goal? The persons goal? The persons goal? 50 51

27 The user personas give us a foundation for user roles and we are especially interested in their goals, which generate story board frames and stories. A brief word of advice The user personas can also be used for UX tradeoffs decisions as well as global conditions and constraints prioritization. Source Impact Map User Persona Who What Stakeholders Features User personas As soon as we are happy with the story board, user interface design gets on our radar. Source Impact Map User Persona Who Stakeholders User personas Story board User persona What Features Features Goal Goal Goal Goal Let s move on to story boarding based on the goals of user personas in combination with the what s from impact mapping. STORYBOARDING A storyboard illustrates user interactions to achieve a goal. The board is written from a specific user persona perspective and it consists of a series of frames, which are visualized similar to a comic strip. Each frame shows sample data. High-level features are associated with each frame. WIREFRAME A wireframe is a rudimentary skeleton of an interface. These are specifically designed to understand the space and structure of the web site or app, primarily aimed at capturing the usability and functionality. Wireframes are quick to create as they only display the web site s framework with little or no details, color or graphics. We prefer to draw them on white board and take pictures for sharing and storage. Main menu Storyboard Main menu Report time Review Report Take time Settings Report Time Review Report Take Time Settings Time reporter log in Time reporter time spent Time reporter Review time report Time reporter Clock time for work task Admin Set project variables

28 As responsive design is a driver, we make wireframes for both web browsers and mobiles. Wireframes have helped us to capture usability and we skip a mockup, and let detailed user interface design evolve during implementation. Let s go back to the story board backbone and proceed with feature decomposition. Let s make this baby rock: 1. Turn identified high-level features into user stories simply by adding a description in accordance with the format above telling who, wants what and why. Feature becomes user story title (more or less). STORY WRITING A user story is written from a user-centric perspective and it describes: who want what and why The user story title works as a short summary. Title As a I want n online customer So that to pay my order by credit card I avoid the risk of losing money Pay by credit card Title As a I want So that (user role) (some capability) (some goal) 2. Organize stories in accordance with the story board. Place stories beneath corresponding frame (and feature). 3. Estimate the effort associated with each story by means of planning poker User stories were initially written, processed and kept on index cards Nowadays, user stories are managed and stored electronically, but a workshop is much better off using index cards, or post-it notes, to make everyone attending the workshop deeply involved in the process and being able to contribute in an easy way. The goal is to get everyone writing stories - and learn that it is great fun. See planning poker description on page? 54 55

29 4. Mark stories with story points estimates 5. Prioritize which user stories that add most value or is necessary to do early for technical reasons. 6. Place prioritized stories high on the map. As a rule of thumb, all stories above 5 story point size need further decomposition, but before story splitting we spend some time validating what we got so far. ROAST THE STORY BOARD We take a step back and look at the complete picture and simulating the use of the product. We are looking for omissions, wrong design, look and fell; We recommend; story splitting workflow (page?) for further reading, but practical experience is really what counts - just do it. What makes a good split is dependent on iteration length, integration, build and deployment process. Smaller stories are always better but require continuous integration/deployment opportunities at hand STORY DETAILING A user story is an invitation to a conversation, means that our initial user story description must be discussed and processed from business, test and coding perspectives, many times, before the story is ready for implementation. The user stories created so far is only half the story; a complete story contains significantly more information, where the most important is the acceptance criteria. Though it s hard to pick acceptance criteria out of the 1. Is there anything that looks strange? 2. Should we change the workflow, logical order? 3. Is the user interface easy to use? Main Report Review Take Settings After menu a few simulation time cycles, including report changes and time adjustments, we all agree that: This is it. Let s do some story splitting. STORY SPLITTING R2 R2 R2 The general guidance favor vertical slices before horizontal slices, e.g. splitting at data types rather than workflow. Use this step wise checklist of R2 R2 R2 common splitting patterns to choose splitting technique: 1. Workflow steps or CRUD 2. Data types or parameters 3. Business rules or interface variations 4. Effort variation or defer performance 5. Break out a spike R2 air, we need a better, methodical approach. An acceptance test case, written in Behavioral Driven Development format, describes an implemented user story s expected behaviors. It matches perfectly with the user story technique and if test data are included it makes the outcomes crystal clear

30 Given some initial context( the givens) And to connect multiple givens When an event occurs Then ensure some outcomes And to connect multiple outcomes A word of advice Use traditional test cases if you are more familiar with that technique. What matters is to capture the outcomes and hence the acceptance criteria. 1. We start to talk about how we are going to demo the implemented user story and write a test case/scenario (happy path), where the expected outcomes fall out as an acceptance criteria. 2. Then, we discuss if there are any alternate paths to be demoed and what their expected outcomes are. These are our next set of acceptance criteria. 3. When we talk about test cases we realize that the initial user story needs further clarification or perhaps needs to be split into two user stories. Clarification often leads to yet other acceptance criteria. 4. We also get ideas on how the implementation should be done. Implementation details usually add acceptance criteria. 5. Finally we discuss whether there are any conditions or constraints that the specific user story must meet e.g. performance criteria or business rules. These become acceptance criteria and test cases as well. 6. The identified acceptance criteria, acceptance test cases and additional information is written down, either on the back of index card or else on additional post-it notes. 7. Use the INVEST model as our definition of ready: Independent. Reduced dependencies = easier to plan Negotiable. Details added via collaboration Valuable. Provides value to the customer Estimable. Too big or too vague = not estimable Small. Can be done in less than a week by the team Testable. Good acceptance criteria and test case 8. Take relevant action, if any INVEST criteria fails. The conversation about our user stories from confirmation/implementation perspectives not only helped us capture acceptance criteria, omissions and specific conditions/constraints were found. The continuous talking has validated the user stories. A word of advice if an electronic storage format is preferred, do this administrative task after the workshop. PULL FROM THE STORY BOARD We are done with the stories and we need a look-ahead plan before pulling the first stories for implementation. Release planning couldn t be easier: 1. Draw a line across the story board to mark what s included in 1st release. 2. Mark stories with 1st release. 3. Calculate the total number of story points for 1st release 4. Divide release in iterations based on team velocity (or by guessing if no historical data exist) Source Impact Map User Persona Who What Stakeholders User personas Ace Test Story board User persona Acc Crit. + Conditions Constraint User Story User role What Features Features Capability Goal Goal Goal 58 59

31 EXTRACT AND WRITE DOCS An agile team working collocated would be fine keeping the release plan in this visualized format but most organizations have policies and standards pointing at templates or tools. Main menu Report time Review report Take time Settings R2 Release goal R2 R2 R2 R2 R2 R2 Most modern collaboration tools manage user stories, acceptance criteria, test cases, story points, sketches, and release/iteration labels etc. Required documentation can easily be extracted it is just a click away

32 A REQUIREMENTS GUIDE: All you need to know about requirement but were too afraid to ask about 1. Core steps when working with requirements: write them, break them and test them 2. Core steps guide write them: (format guides connextra, conventional, verb+objects, visualize+text, acceptance criterias, write+model gives context, global constraints non-funktional req, business rules, textual storyboards, graphical storyboards, catch-them strategies - questions Core steps guide break them: Modelleringstekniker - use case light, fractal mapping, process model/swimlanes, splitting strategies, domain-driven, pros/cons modelling Core steps guide test them: Roast validation is key, BDD, Invest, review walkthroughs, test examples test cases, business tests, validation strategy 3. The story of the story (image cone of uncertainty meets the butterfly metaphor) /connext back to loops) 4. Our 2 cents on agile requirements: We love nominal group technique because We recommend JAD because We strongly believe that agile estimation is all about requirements because.. We think a good facilitation strategy needs to take this into account. ijijijij 62 63