Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
A User Story is just that. It is a non-technical description of what the user of a system desires or imagines. It is written from the specific user's perspective and it is at the core of the Agile method. It is NOT a specification. It is intended to be a user's view of a desired outcome, trusting in the team (the Scrum team) to apply their expertise to design and create the best solution in the time allowed. Due to the nature of Agile project engineering, it is also very necessary that the User Story be small - in other words, it describes something that can be fully built in a small amount of time. The process for developing User Stories varies, but in project work, it is assumed that you will take the business requirements at a higher level and break them down - level by level - to get to the actual Stories. This process may not be simple, fast, or easy, but it is essential to the success of Agile development that we break down our ideas into the smallest implementable parts before attempting to "Sprint" on them. Without properly formed Stories, Sprint development gets quickly bogged down into questions of scope and definition that obscure the solution and generate tension in the project team. User Story development is an essential skill and unique tool for building clarity and consensus in your project scope, and well-built stories will help the Scrum team to satisfy and delight your customers. What you need to know to write great User StoriesThe best User Stories follow the INVEST acronym Independent, Negotiable, Valuable, Estimable, Small, and Testable The Agile method was developed to embrace constant change and emphasize working together as a team to develop the "right" solution with continuous customer feedback. User Stories are a simple way to capture scope in specific contrast to lengthy business requirements. The Agile method emphasizes conversation over documentation. Get the important aspects down as a User Story, and let the team ask questions to get the clarity they need. Business vision needs to be recorded at the right level and provided to the Scrum team in a manner that answers some questions but also generates dialogue between the team and product owner - you will be able to tell that a Story is not well formed if the questions it generates are too many or too complex. A standard has been accepted as a good model for User Story format: As a [specific role], I want [functionality] so that [goal/benefit which clarifies the functionality]. For example… As a Facebook member I want to be able to set different privacy levels on my photos so that I can control who can see my photos Some Product Owners will find this easy to do, but others will need the help of the business analyst to get to the right User Story shape and size. User Story size - INVEST Each User Story that the BA and product owner create needs to be small enough to be completed in just one Sprint, including analysis, development, QA, and acceptance testing. In fact, Agile recommends the Story be small enough to be completed in one DAY! That means that the coding, testing, and acceptance are all done. To help you to write better Stories, there is an acronym used by the industry to define a "good" Story: I.N.V.E.S.T.… I - Independent: the Story does not rely on other Stories and can be developed on its own by a single Scrum team. N - Negotiable: the Story is well understood by the customer, but open to change and insight. V - Valuable: the Story defines something that is truly important to the business. E - Estimable: the Story is clear enough that the Scrum team is able to estimate the work involved in building & testing it. S - Small: the Story is an increment of the whole and can be completed in a short time (one day, ideally). T - Testable: the Story asks only for things that can be proven, shown, and tested. Please notice, then, that smaller is better. Small Stories are easy to understand and complete. If the Story is too large, it must be broken down into multiple, smaller Stories. The Scrum team is encouraged to request further breakdown whenever they feel a Story is too complex or too large. Acceptance Criteria IMPORTANT: Acceptance Criteria are never a replacement for conversation. Agile uses acceptance criteria as a reference point and simple documentation. All this should be able to be recorded on a 3 x 5 index card. In fact, the product owner should be the one to clarify any questions about acceptance criteria - not the few words recorded with the User Story. Acceptance criteria should help the Scrum team form the solution but they should not define it. According to industry standards, "good" acceptance criteria…
UX Acceptance criteria Whenever a product has a user interface (and most of them do) it is necessary to also get acceptance of a solution from the User Experience (UX) team. In some cases, this may take the form of additional acceptance criteria or attachments to the User Story, although I would avoid using Acceptance Criteria for UX guidelines since these guidelines apply to all or many User Stories and since overall design approval is not a Story-level activity. UX guidelines do not replace verbal communication and if the UX team is not part of the Scrum team it probably should be, if possible. Epics & Features In Agile, if a Story is too large for the Scrum team to consume in one Sprint, it is considered an Epic. An Epic is just a large Story, but it has evolved in enterprise IT to become a tool for capturing the requirements as a hierarchy of larger Stories broken down to reach smaller Stories. A sample Epic might be: "As a lead analyst, I want to hold an online ratings committee so that people can see, discuss, and vote on my criteria from their desks, without having to be in the room." Clearly, this is too large to be used as a user story for a single sprint, but it is a good tool for showing the product owner that we understand their requirements and then breaking that large story into smaller, implementable parts. Agile Down-to-Earth recommends that in the Requirements phase, you capture the entire scope of your project as a series of high-level Epics, and then break them down. We also recommend a two or three level Epic hierarchy where the lowest level Epic is used to define the Features of the solution will help to elicit the entire project scope. But are your Stories ready for Sprinting?A "Complete" Story Okay, you have written a great User Story. Are you ready to go into your first Sprint? Probably not yet. Let's go to the checklist - A complete Story… 1.) Has all of its acceptance criteria 2.) Has been estimated (in Story points) 3.) Has had its "technical risk" assessed 4.) Has been prioritized and ranked by business value by the product owner. If you are in the Requirements phase of your project, then most of your Stories should have these before moving to the Sprint phase. Also, once you reach the Sprint phase, only "complete" Stories should be passed to the Scrum team for Sprinting. Release management As an Agile best practice, we should define and commit to a complete release scope before beginning to Sprint. In order to do that all Stories must be roughly estimated. Only the most highly ranked (business value) Stories should be considered (In Agile Down-to-Earth, we believe that you should include the most technically risky stories in your rank of most valuable). The total number of Story points for your next release will be held as a fixed target. Then, using a team's velocity will tell us when it should be finished. So, get your Stories in shape before release planning begins and your rough estimates will be a more accurate reflection of the size and schedule of your phase. Sprint planning A note about Sprint Planning, a Scrum meeting that takes place at the beginning of each Sprint… If your Stories have already been estimated in the Requirements phase and nothing has changed, then do not change the Story point estimate now. But, if Backlog Grooming has caused the Story to change, or split, or if it has new acceptance criteria the team should re-estimate in Story points during Sprint Planning. Of course, whenever a new Story has been introduced by the product owner, you will need to estimate that in Sprint Planning, too. Article SummaryThe key object to communicate business requirements in Agile is the User Story. Consistent application of standards and quality in User Story development greatly helps to drive the quality of your development and project success. Not following these industry-wide standards leads to confusion and can lead to significant customer dissatisfaction. But, as important as the User Story is, there is nothing more important than face-to-face (ideally) verbal communication between the Scrum team and the product owner. Never blame the Story for a misunderstanding. Talk, ask questions, and work together to get to clarity. Small Stories help this. If your team is asking many questions about a Story, chances are it is too large or complex. And let the User Story speak for the customer, but avoid putting the solution into the Story - not even the acceptance criteria. Allow the Scrum team to come to the best solution to meet the customer's needs. That is basic to Agile. Trust the team to dig and find the best solution. It has been proven widely that when Agile practices like these are followed faithfully, the resulting product is more in line with customer needs, more flexibly responsive to change, and maximizes the value of the project team.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |