Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

User Stories

•Download as PPT, PDF•
•
S
scornelius

A short presentation about writing requirements in the form of user stories for use in agile development projects.

1 of 20
User Stories
User Stories What Are User Stories? Story Format Acceptance Criteria Sizing Stories Questions
What Are User Stories? They are a way of capturing requirements that works well for agile development. They’re a simple description of a discrete bit of functionality which can be implemented inside one iteration. They’re written on index cards for use in planning or development.
What Are User Stories? They comprise a description of the bit of functionality in question, supporting information such as UI snippets, and a set of acceptance tests. The literature gives various ‘templates’ for how stories should be written. Most teams will evolve their own format which works for them.
A Real Life Story Card Story Title Story # Effort Estimate Acceptance Criteria Status Indicators Dev Started Dev Finished Tester tested Customer accepted
Story Format A number and simple descriptive title. The standard format has a description like: As a <type of actor> I want to be able to <do something> so that I <reason for doing>. E.g. As a site administrator I want to be able to edit the homepage so that I can update the marketing promotions . It’s useful to think about why and for whom you want to do things, but it gets a bit cumbersome. In practice this description might get condensed to ‘ Edit Homepage ’.
Acceptance Criteria Most of the detail in stories comes in the ‘acceptance criteria’. These are written from the perspective of the person requesting the functionality. They describe what the person had in mind, and allow the team to determine when the story is done . They’re effectively a little UAT script
A Simple Example I want a banner ad to appear at the top of the homepage Marketing Person A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step
A Simple Example So they tell me this is done.. Let’s see.. Step 1 – yep.. Step 2 – okay.. ..perfect, I can sign this off. A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step
Acceptance Criteria Whatever the ‘bit of functionality’ is, it’s being done for a reason. It delivers value to someone: End user (proxied by product team) Developers Site Administrator Architect Etc Identify who is asking for the functionality, and hence who will sign it off. They define the acceptance criteria…
What About Technical Stories? I want to move the login code to the new controller framework… so my acceptance criteria are that I swap out the code and all the existing tests still pass! A Developer
Or More Technical Criteria.. I want to be able to produce an RSS feed out of the manifest XML that arrives as part of a data delivery. Format spec <rss> <channel> </channel> <item> … </rss> Note that it doesn’t say – “run x file through xsl stylesheet and..” – the person signing off can’t see that and doesn’t care how it works. Production Guy The XML file follows the RSS2.0 structure described in the attached document. 3 – Examine XML file. An XML file entitled DDMMYY.xml appears in the directory. 2 – Open a command line and run the conversion tool, e.g. makerss <nameofzip> Find the weekly delivery zip file e.g. 090107.zip. 1 – Go to the holding area server1emp Expected Result Step
Acceptance Criteria vs Testing Acceptance criteria should include general error scenarios: “ Attempt to submit the form with an invalid username - see client side error x.” But a product owner is not a professional tester and stories will not cover every possible detailed issue. What happens if I enter an &? Or quotes? Or a Chinese character? Break, damn you..!
How Big Should Stories Be? Stories should describe a discrete, logical piece of functionality. They should be the right size for your iteration lengths – they must be developed, tested and signed off within one iteration. Smaller is usually better. Smaller stories are easier to write, easier to estimate and easier to test.
Judging Story Size With experience you get a feel for how big a story is likely to be. If in doubt, ask the advice of the developers. Too-large stories can almost invariably be split up. Again the developers can help identify logical breaks. I want a banner advert at the top of the homepage. If a user logs in I want it targeted by their country of origin, and by their special interests. I want an admin system so that I can set up the ad. I want a…
Breaking Stories Down Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts.
Breaking Stories Down Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts. Show Book Title Show Cover Image Show Price Show Discount Show Stock Status
Questions These type of “requirements” miss loads of detail. What about…? They aren’t meant to capture every conceivable detail. Remember this is an agile project. If something is missing you go ask.. And the customer has to give you an immediate answer. It’s all about conversation.
Questions Won’t a product designed this way be an incoherent collection of tiny pieces? That can happen, if you don’t do it properly. It is very important to keep thinking about your overall product vision and how each story contributes to the whole.
Questions?

More Related Content

User Stories

  • 2. User Stories What Are User Stories? Story Format Acceptance Criteria Sizing Stories Questions
  • 3. What Are User Stories? They are a way of capturing requirements that works well for agile development. They’re a simple description of a discrete bit of functionality which can be implemented inside one iteration. They’re written on index cards for use in planning or development.
  • 4. What Are User Stories? They comprise a description of the bit of functionality in question, supporting information such as UI snippets, and a set of acceptance tests. The literature gives various ‘templates’ for how stories should be written. Most teams will evolve their own format which works for them.
  • 5. A Real Life Story Card Story Title Story # Effort Estimate Acceptance Criteria Status Indicators Dev Started Dev Finished Tester tested Customer accepted
  • 6. Story Format A number and simple descriptive title. The standard format has a description like: As a <type of actor> I want to be able to <do something> so that I <reason for doing>. E.g. As a site administrator I want to be able to edit the homepage so that I can update the marketing promotions . It’s useful to think about why and for whom you want to do things, but it gets a bit cumbersome. In practice this description might get condensed to ‘ Edit Homepage ’.
  • 7. Acceptance Criteria Most of the detail in stories comes in the ‘acceptance criteria’. These are written from the perspective of the person requesting the functionality. They describe what the person had in mind, and allow the team to determine when the story is done . They’re effectively a little UAT script
  • 8. A Simple Example I want a banner ad to appear at the top of the homepage Marketing Person A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step
  • 9. A Simple Example So they tell me this is done.. Let’s see.. Step 1 – yep.. Step 2 – okay.. ..perfect, I can sign this off. A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step
  • 10. Acceptance Criteria Whatever the ‘bit of functionality’ is, it’s being done for a reason. It delivers value to someone: End user (proxied by product team) Developers Site Administrator Architect Etc Identify who is asking for the functionality, and hence who will sign it off. They define the acceptance criteria…
  • 11. What About Technical Stories? I want to move the login code to the new controller framework… so my acceptance criteria are that I swap out the code and all the existing tests still pass! A Developer
  • 12. Or More Technical Criteria.. I want to be able to produce an RSS feed out of the manifest XML that arrives as part of a data delivery. Format spec <rss> <channel> </channel> <item> … </rss> Note that it doesn’t say – “run x file through xsl stylesheet and..” – the person signing off can’t see that and doesn’t care how it works. Production Guy The XML file follows the RSS2.0 structure described in the attached document. 3 – Examine XML file. An XML file entitled DDMMYY.xml appears in the directory. 2 – Open a command line and run the conversion tool, e.g. makerss <nameofzip> Find the weekly delivery zip file e.g. 090107.zip. 1 – Go to the holding area server1emp Expected Result Step
  • 13. Acceptance Criteria vs Testing Acceptance criteria should include general error scenarios: “ Attempt to submit the form with an invalid username - see client side error x.” But a product owner is not a professional tester and stories will not cover every possible detailed issue. What happens if I enter an &? Or quotes? Or a Chinese character? Break, damn you..!
  • 14. How Big Should Stories Be? Stories should describe a discrete, logical piece of functionality. They should be the right size for your iteration lengths – they must be developed, tested and signed off within one iteration. Smaller is usually better. Smaller stories are easier to write, easier to estimate and easier to test.
  • 15. Judging Story Size With experience you get a feel for how big a story is likely to be. If in doubt, ask the advice of the developers. Too-large stories can almost invariably be split up. Again the developers can help identify logical breaks. I want a banner advert at the top of the homepage. If a user logs in I want it targeted by their country of origin, and by their special interests. I want an admin system so that I can set up the ad. I want a…
  • 16. Breaking Stories Down Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts.
  • 17. Breaking Stories Down Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts. Show Book Title Show Cover Image Show Price Show Discount Show Stock Status
  • 18. Questions These type of “requirements” miss loads of detail. What about…? They aren’t meant to capture every conceivable detail. Remember this is an agile project. If something is missing you go ask.. And the customer has to give you an immediate answer. It’s all about conversation.
  • 19. Questions Won’t a product designed this way be an incoherent collection of tiny pieces? That can happen, if you don’t do it properly. It is very important to keep thinking about your overall product vision and how each story contributes to the whole.