This document outlines Softjourn Inc.'s user story workflow process. It discusses the differences between releases and versions, and the stages a user story goes through: start, progress, and end. Releases group together versions, which contain user stories. User stories go through analysis, development, and testing stages. Test cases are created and stored in the company's Redmine wiki to validate user stories.

1. User Story Workflow
04/07/2012

2. Softjourn Inc.
User Story Workflow
Anatoliy Okhotnikov
Softjourn Inc.

3. 7/4/12
Agenda
● What is it about?
● Releases vs. Versions
● User Story Stages
● Test Cases

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. Releases vs. Versions

6. Releases vs. Versions

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. Releases vs. Versions

9. User Story Stages
 Start User Story
 User Story Progress
 End User Story

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. User Story Progress
 Should have unit tests
 Should have sufficient inline code
documentation (phpdoc, javadoc, etc.)
 Should comply to framework's 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. 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. 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
 We'd 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. Questions & discussion
“Anatoliy Okhotnikov”
<aokhotnikov@softjourn.com>
Copyright © 2000-2011 Softjourn, Inc. All rights reserved