User Story workflow best practices (from ready to done and rollout)

Question

When implementing a big project usually we have specialized teams in charge of a specific task such as Validate the User Story is Ready to be implemented, Testing, etc. Sometimes to just get the User Story Ready (well documented) its a project itself.

Once the User Story is ready, we start the implementation, testing and finally the rollout. The user story documentation starts with the high-level feature (Epic) that should be documented. Once we have this, then we start defining more detail features (in terms of user stories linked with a given epic).

I would like to know the best practice in JIRA for handling such kind of scenarios. We are thinking of using the following design solution:

Define the following states for the User Story:

* TO-DO
* DOCUMENTING
* PENDING FOR VALIDATION
* READY

Then once the story is ready to implement, to continue with the following states:

5. DEV,

6. TEST

7. DONE

8. ROLLOUT

(probably via a workflow)

Note1: For Testing, we can consider sub-tasks associated with the User Story and define a specific workflow that emulates the testing process. Then for integration testing that considers the interaction of several User Stories, define a User Story of type: "Test Case". For sure there are better options too. The thing is that some customer requires to document the test case, even it can be automatized or integrated with xRay for example.

Then use the following dashboards:

* Documentation Dashboard: Takes the user stories from TO-DO until READY
* Implementation Dashboard: Takes the user stories from DEV to ROLLOUT.

I know it looks like a little bit Wagile. We are transitioning and this is the best way we are organized so far. Perhaps in the future, we can improve this organization, through retrospective meetings.

Please advise how this strategy could be implemented in detail or any other possible strategy you consider fits better.

Thanks in advance,

David

Note2: This is not the first time I found this can of project configuration, I am surprised I haven't found a specific question about this problem here.

David Leal_28ge8x · Answer

Thanks, Peterson for your rapid answer. Yes, sorry I meant "Board" instead of "Dashboard" as you correctly interpreted. Thanks for the tip for the testing process. Then for this purpose, we would need to create specific User Stories for testing (for time tracking purpose)? That would duplicate the effort creating a bunch of User Stories of type: Test Case.

The sub-tasks approach can keep the traceability at Story level, and we can identify the number of User Stories tested based on the transition from the state: TEST to DONE for example in the implementation Board. Let's say the Testing team is planning to test for the next Sprint 20 User Stories (there are in state TEST), that represents 50 story points. Then at the end of the Sprint looking at how many User Stories were moved from TEST to DONE provide a kind of the testing team velocity. A User Story can be moved once all the associated tested sub-tasks finished.

Then creating User Stories linked from the Epic (or even linking several US at the same time) for integration testing. For those, such information can be tracked with Jira Reports (i.e. Burn Up/Down Diagram).

Any thoughts (I know both options have pros and cons)? Thanks in advance,

Petter Gonçalves · Answer

Hello David,

I think that the way you are configuring your scenario on JIRA is one of the most common and efficient ways to organize your user stories and procedures.

The status you mentioned for the documentation and rollout of the Stories can be configured in the same workflow, however, configuring two different views (Boards) to display only the relevant statuses for the documentation team and the development team.

I just have one question about this sentence:

Then use the following dashboards:

* Documentation Dashboard: Takes the user stories from TO-DO until READY

* Implementation Dashboard: Takes the user stories from DEV to ROLLOUT.

When you say dashboards, are you meaning the dashboards of JIRA itself where you can configure gadgets or you are meaning the kanban/scrum boards related to software projects?

Per your description, I believe that you are talking about a Kanban or Scrum board. If that's the case, you are indeed using a good practice to split both processes of the issue into two boards: one for the documentation and other for the rollout.

The idea of sub-task to make the tests required is also a good practice, however, sub-tasks cannot be estimated on JIRA reports, so if you are planning to use time tracking I would recommend you to use the relation Epic-Stories instead of Stories-Subtasks.

that being said, I believe you are in the correct path to organize your development plan, David.

Please, let me know if you have any specific questions about the scenario you are configuring.