User story workflow (eng)


Published on

● What is it about?
● Releases vs. Versions
● User Story Stages
● Test Cases

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User story workflow (eng)

  1. 1. User Story Workflow04/07/2012
  2. 2. Softjourn Inc.User Story Workflow Anatoliy Okhotnikov Softjourn Inc.
  3. 3. 7/4/12 Agenda ● What is it about? ● Releases vs. Versions ● User Story Stages ● Test Cases
  4. 4. What is it about? Process document in the Wiki http://wiki.sjua/process:newproject:userstories Our practice when we  Start project  Run project  End project Weekly/Daily practice when handling User Stories
  5. 5. Releases vs. Versions
  6. 6. Releases vs. Versions
  7. 7. Releases vs. Versions Create release Release#1 - dates and story points Create version Backlog#1 Using ”(metrics)” admin tool assign Backlog#1 to Release#1 Create user Stories in version Backlog#1 If the team works with the sprints/milestones (optional)  Create version Sprint#1  Using ”(metrics)” admin tool assign Sprint#1 to Release#1  Move user stories from Backlog#1 to Sprint#1
  8. 8. Releases vs. Versions
  9. 9. User Story Stages Start User Story User Story Progress End User Story
  10. 10. Start User Story Must be analysed (complex User Stories >= 8 points must and 5 points should have team design meeting) — “Next” status Must have Test Cases (at least informal ones - a couple of sentences) as the result of analysis stage before “In Progress” Must be discussed by the team before voice status with a customer and questions/issues must be communicated to a customer if any
  11. 11. User Story Progress Should have unit tests Should have sufficient inline code documentation (phpdoc, javadoc, etc.) Should comply to frameworks coding standard (pass checkstyle tool) Should pass static code analysis tools checkes Before Developer Done, the developer should run through Test Cases Work done must be committed only, avoid committing incomplete work to SCM
  12. 12. End User Story Must end one 24 hours before the deadline (sprint/version end) Must be tested within 24 hours of the Developer Done with Test Cases If there are issues after 24 hours after Developer Done (bugs, not tested) - record an issue in Redmine
  13. 13. Test Cases Store in Redmine project wiki linking to the User Story User Story links back to the Test Case wiki page Free form — the only requirement: it must clearly state the result of the User Story  Wed like to see test steps, if possible :) You can nest and branch Test Cases as much as you like — wiki structure/syntax to the rescue! http://wiki.sjua/process:newproject:rmwikitc
  14. 14. Questions & discussion“Anatoliy Okhotnikov”<> Copyright © 2000-2011 Softjourn, Inc. All rights reserved