This post originated from an RSS feed registered with Agile Buzz
by Mark Levison.
Original Post: Lifecycle of a User Story
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
User Stories are often used as a lightweight form of Agile requirement. Their goal is to replace heavy weight-specification documents with “a Card, a Conversation and a Confirmation”. When people first discover User Stories its hard to see how they work because we often take a static viewpoint – i.e. we only see them at Release Planning or during implementation. We’re left with many questions: Where do User Stories come from? When are they created? Who is involved in their creation? To illustrate this I will use vignettes from the WorldsSmallestOnlineBookStore. Each vignette will show what happened to one User Story. “As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore” During the team’s first Release Planning Session (aka Initial Product Backlog Refinement) this Story was identified. After a few rounds of planning poker the consensus estimate was that it was size 20, allowing for both the initial entry of the address, updating and deleting old addresses. Since this Story appeared to be low priority in the short term, the team moved to other items. …. In Sprint #5, during a Backlog Refinement session, the PO Sue revisited the Story and asked the team if their understanding of the problem had changed in the past two months. They conferred for a few minutes and decided that it was still a 20. Sue grumbled and suggested it was a fairly small piece of functionality for such a large number. Doug suggested a Story split – using CRUD (Create Read Update Delete), he proposed in the short term that the User be allowed to add a new address and use it. However, they wouldn’t be able to update and delete. This would separate the Stories. After a few minutes of conversation around the implications Sue asks them to estimate the three split Stories: “As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore.” “As a frequent book buyer I want to delete old addresses so that I don’t have to worry that my books will ship to the wrong house.” “As a frequent book buyer I want to update my existing address to correct small errors so that I don’t have to retype them from scratch.” The team determines the “save address” Story is size 8, the “delete address” Story size 5, and the “update address” Story size 8. Based on this Sue moves the “save address” Story to the top of the Product Backlog, “delete address” about 15 items further down and “update address” has been moved so far down it will never be tackled. Since the slimmer “save address” is now the top Story in the Product Backlog without acceptance criteria, the team spends a few minutes creating criteria for it. They start off by drawing a quick pencil sketch to get the key points across. Based on this sketch they start creating a table of examples: 1 Sussex Drive, Ottawa, Ontario, Canada, K2K 010 Valid Buckingham Palace, London, UK Address outside of Canada/US 1600 Pennsylvania Avenue NWWashington, DC 20500 Valid Rather than try to create an exhaustive list at this point they just create enough to outline the boundaries of the problem. During the team’s next Sprint Planning session, Sue asks if the team can commit to this Story. They give it the “thumbs up”. Before the team starts work on the Story, Tonia (QA specialist), Brad (BA), Doug (Developer) and Ian (Developer) meet to finish hammering out the acceptance criteria. 915 E 7th St. Apt 6LBrooklyn NY 11230 Valid 24 Willie Mays Plaza, San Francisco, CA 94107 Valid 24 Willie Mays Plaza, San Francisco, CA No Postal Code 24 Willie Mays Plaza, San Francisco, 94107 No State 45 Rosenfeld CrOttawa, ON K2K 2L2 Valid 45 Rosenfeld Cr, Ottawa, ONK2K 2L2 Valid 45 Rosenfeld CrOttawa, ON K2K 222 Invalid Postal Code 45 Rosenfeld Cr, Ottawa, ON Missing Postal Code …. (This style is referred to as Specification By Example – where the emphasis is that it provides the specification before something is built). Brad goes off to see if there are any edge cases that the examples don’t cover. Ian and Tonia pair off to turn the examples into Executable Specifications (i.e. acceptance tests) in Fitnesse[1]. Doug starts to take a crack at the GUI, seeing what parts he will need to assemble. Once the initial tests are written Ian tries build the business logic to support the examples. A few days later when Ian and Doug think they’ve completed the Story and it meets the examples, they show it to Tonia. Once she sees that satisfies the test cases she spends a while doing some exploratory testing – seeing how the application behaves when a real User plays with it. Satisfied, she calls Sue over for additional feedback. Sue is delighted with the behavior but asks for a few changes to the layout. Once those are made she agrees the Story will be complete. During the Sprint Ian demonstrates the different ways we can now support accepting addresses from both Canada and the United States. At the end of the Sprint the team takes the completed Story off the wall and archive it in the filing cabinet (they keep them around for later auditing) ——— During Sprint #6, Brad (BA) sees Ian (Developer) in the hallway and they start chatting about the warehouse runners, i.e. the people who fill the book orders. Brad comments he’s seen the runners spend a lot of time retracing their steps because the list of books in for an order is alphabetical – but unfortunately the warehouse isn’t laid out in alphabetical order. They create a new Story: “As a runner I want the list of books to be printed in the same order I will find them in the warehouse so I don’t have to run as far” During the Backlog Refinement […]
Previous Topic
