Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
The prioritized product backlog is core to being Agile. A well prioritized backlog allows us to satisfy the customer through early and continuous delivery of valuable software at then end of each sprint in Scrum. Lean and Kanban may call it something else, but there too, prioritized work is key.
In Scrum, the standard format of a user story is easy to understand: “As a [role] I want [something] so that I can [benefit].” However, there is more difficulties inside the project team to agree on what constitute the content of a user story. In this blog post, Steve Johnson explores this issue.
User stories are the foundations of the Scrum sprints as they would allow you to work on the right things. Charles Bradley provides a lot of interesting material about crafting good user stories in his Scrum Crazy blog. In a blog post he starts by discussing what a user story is and go right to the point is saying that a user story is NOT a “As a I want so that”. For him, a user story is more than this and should consist of three parts: 1) a written description or short title of the story used as a token for planning and as a reminder to have conversations, 2)conversations about the story that has the details of the story, 3)acceptance tests that that can be used to determine when a story is done.
One of the first steps in an Agile adoption is the formation and organization of agile teams. Leadership often struggles to figure out how many people should be on each team, what skill sets should included, and whether the team should be focused on solution components, feature delivery, or a mix.
Learn how you can improve your business analysis with Agile story mapping, a technique that maps your stories back to business value. Thus you will be able to know if they make or save the company money and you will learn the benefits of bi-directional requirements traceability .
The “rightsizing” of user stories occurring during the planning of the next sprint in Scrum is not always an easy task to perform. Inexperienced teams have difficulties to split user stories into smaller chunks that still deliver business value and would rather use technical criteria. In this blog post, “Specifications by Example” author Gojko Adzic provides a new approach to achieve this goal using the hamburger as a reference. You identify the tasks making up a user story. Then you use this breakdown to identify different levels of quality for each step and create vertical slices to identify smaller deliverables, thus creating your next sprint’s hamburger.