3. This kind of story... Title: Comment Page - Thank you page Description: As a stakeholder In order to let my customers know I appreciate them providing feedback I would like them to receive a thank you page letting them know we received their comments and appreciated them. Acceptance Criteria: A thank you page should be displayed upon customer submission of a comment.
4. What? User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.
24. Title: SEO - County Search Page Updates Description: In order to accomplish higher rankings by search engines, as the SEO person, I would like to have the new county search page (/search/county/) updated so that the title, the meta description, and the H1 tags are more relevant. Acceptance Criteria: Title should have the following:<COUNTY NAME> County Home Rentals, Apartments for Rent, Homes or Houses for rent in <COUNTY NAME> County <STATE ABBR> | RentalHouses.com Meta Description should have the following:Home Rental Listings in <COUNTY NAME> County <STATE NAME>. Information and listings for available homes for rent in <COUNTY NAME> County <STATE ABBR>. Find the perfect house for rent in <COUNTY NAME> County to fit your monthly house rental budget on RentalHouses.comH1 should have:<COUNTY NAME> County Home Rental Listings
Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.
invest is just an acronym we can use to help us make useful story cards.
Stories should be as independent as possible. Many times we can’t make them independent but if it is possible to do so then we should. Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order.
For instance a stakeholder asks for a multi select drop down maybe the developer asks well you could have a multi select drop down but we only have 4 options it would cost much less to do it as check boxes...
A story should represent some value to the customer. The stakeholder should be able to define the business value the story provides. Sometimes we want cards around things that only the developers see as important such as cleaning up technical debt and these are valid but you have to be able to frame it in such a way that they are perceived as important by the customer.
You should always be able to ball park guess how long it will take you to complete. This basic function is to be able to allow the customer to rank and schedule the implementation. If the story is too vague or doesn’t met some of the other invest guidelines then a lot of times the story will be difficult to estimate and should be a smell that the story might not be a good one.
The story should be doable in an acceptable amount of time. A good rule of thumb is that a story should never take longer than one iteration and usually should be a much smaller portion of the iteration than that. If a story is estimated as a large (greater than a 4 point story in our environment) it should be broken down. Smaller stories usually have more well defined scope and its easier to really know what is expected out of the story.
You should be able to create clearly defined acceptance criteria for the story. It should be very easy to tell when the story is done. If its not something that you can clearly create acceptance tests for then its probably not a well written story. When a story card is written it creates a kind of promise from the customer that they actually understand what they want well enough that they could write a test for it. If they can’t write a test for it then usually that means they don’t really understand it or they don’t really care about it and it probably isn’t adding any real value.
Typically the story description is followed by acceptance criteria that basically answers the questions I have up here. It helps me as a developer know when I am done. It is also usually easy to take the acceptance criteria and create tests.
say for instance we have a “Search Widget” and this search widget is going to be visible on multiple pages on a site.
As a developer I have no idea the complexity level of everything that has to be done for the widget. I can’t estimate it. Sure I could WAG it but the wag is going to be way off. There are a lot of things going on in this widget that we are not truly considering just looking at it. For instance the Save button or the Alert button or all that stuff at the bottom. When I am coding it I want clearly defined acceptance criteria that I can basically build tests from to make sure I am building what the customer really wants. Its a clear small chunk of functionality that I can focus on and get finished. If you told me to estimate this story as a widget level when I look at it I go oh its just a search refinement we have done that before its not a big deal. But in reality as a developer I should be asking questions like well wait what does that save do? So do we have an onsite customer? Are the stakeholders sitting in the dev area at all times ready and waiting to answer those questions when they come up? Most of the time no.. they have other things they need to be doing. I don’t have their attention. What if I just assume I know what you mean? What if I think save means I have to make them login and create an account and I start down the path of building that only to find out that after a week of development (i.e. when it goes to be accepted) that there is actually a system called myservice that I can use to do this?
If you write the story at a widget level then its all or nothing. The stakeholder wants the save button but might be willing to launch without the save and get alert functionality. However they don’t easily see that they can just move that out to save time to launch... If the stories are broken down the stakeholder has an easier time pulling things out without losing them. Additionally, including developers in the process means that they will actually think about what it will take to implement something. Humm keyword search .. what does that mean.. does endeca handle that? How do we do that... what is the keyword search on? Everything in the system or just certain pieces in the system like maybe only city, state, and ad#. Are we doing to have to do full index searching on tables or not?
Well basically you follow the same guidelines. Lets give an SEO story a shot.
So as you see we can also create stories for things without mockups
I often times represent possible epics with the word PLACEHOLDER in the title to indicate the functionality is not really that clear.
Just another image to remind you of the flow of things... this encompasses everything we talked through on the way up to the stuff that was most important to you.. the code part!
![Stories ,[object Object]](https://image.slidesharecdn.com/storiesdeck-091014175019-phpapp02/85/Agile-Storycarding-1-320.jpg)
