How do I track the Creation of a User Story in a Sprint?

Question

Is there a Best Practice for building User Stories via Sprint?

Process:

Epics are created

The Product Team meets to review the Epics .. in particular Epic 1

The Team decides that Epic 1 needs 5 User Stories.

User Story's go through a Discovery Phase, the Story Creation Phase, a Tech Spec Phase, and finally a Review / Sign off.

Issue: We want to have all of that work effort tracked via Sprint / Burn Down ... and that is separate from the actual Development work down once the story is approved.

Currently, all of that is in the User Story Flow and when a User Story is "approved" it merely goes into the Product Backlog to be picked up in the next Grooming/Planning session.

That means the story, in the first sprint, never burns down, as it's not "completed".  Is there a way around this? I assume not, and that means breaking that workflow out of the Story and do it somewhere else.

Question: What is the best way to track / tie it all together so we get a burn down for the "Story Creation" process, as well as a burn down for the "Story Development / Testing" process?

Option 1) Simply create 5 sub-tasks, with the aforementioned workflow.  When the sub-task is done, create an actual User Story issue, transfer the artifact (the actual story / acceptance criteria), and resolve the task/sub-task.

While this option allows for the work effort for creating a user story to be tracked, it seems cumbersome as the work product (the story, etc) are in that task / sub-task and would need to be transferred .. as well as other housekeeping duties.

Option 2) Create a new Issue Type: Story Creation.  Create the 5 issues, work the issuea, get the issues approved, and on transition clone the issues, then change the issue type to "Story".

While this option takes care of the transferring of the work product, it could lead to confusion when searching for issues as the summary is going to be the same.  Also, if the story is rejected in Grooming, then the issue creation has to be re-opened, and go through the process again, and possibly accidentally create another "story".

Is there another option that I have not thought of?

Thanks for the help, I am really wracking my brains to figure out an elegant efficient process.

Thomas Magny-Garcia · Answer

Hi,

I agree it is not the best way to do what you express. But it is the better way for the "Scrum team" I work with (developers + functional analyst - PO).

I deal a lot with the process, we defined a definition of Ready for a Story and in this definition, the Spike (or New Thing for Creating Stories, I really like this explicit term!) has to be Done (and to be done, has to be shared and the resulting Stories validated).

I guess you are facing the same issue than me. In the Agile context, you should select, in the Sprint Planning, stories according to their Story point and your velocity. The analysis (tech specs, reviews...), the development (review...), the tests (QAT, UAT...) should be executing during the sprint. As I understand, you are not able to do all this stuff in one sprint (so am I) and I think it is the issue I try to bypass with this complexity...

I don't know if it helps, but if you find a silver bullet, I'm all ears !

david-guild · Answer

Hi Thomas,

Great Term. Thanks for taking the time to reply.

Creating a new "issue" (or even using sub-tasks) suffers the same issue: Mechanical Complexity.

Epic -> New Thing for Creating Stories

-> Story

New Thing and Story are siblings, and while they can be related, that is not easy to surface in reporting / boards ... as well as not easy to "workflow" together as they are separate.

One of the worst mechanical deficiencies is when a story is rejected in either Grooming or Sprint Planning.  Do you delete the story that is deficient? and re-open the "New Thing" to ultimately create a new User story? Where Story could be rejected again in Grooming/Planning?

I am sure there would be other "gotchas" that we would experience.  I was really curious what other people are doing.  Do most people just "deal" with the complexities? Do they completely separate the Story Creation workflow? do they just not really track/sprint the actual story creation work effort?

At this point, I added / changed a couple of statuses to track stories.   It goes something like this:

Product Backlog

Story Sprint Planning

... story creation, tech specs, reviews, etc, etc

Development Backlog

Development Sprint Planning

... development, review, QAT, UAT, etc, etc, etc

This will be slightly more complex in that users will have to use two boards, but that is a lot less complex then having some form of sibling tasks/sub-tasks.  Plus it handles almost all other concerns.

Again, thanks for taking the time to answer.

Thomas Magny-Garcia · Answer

Hi @david-guild 
As I understand your issue, I suggest you to use another type,  the Spike. (I will give you the (really good I think) definition from the glossary of Innolution : 1. A term that originated with Extreme Programming (XP) that is used to refer to work whose primary purpose is explore potential solutions or otherwise gather information. A way to acquire knowledge when the situation at hand has uncertainty as to the proper or good way to proceed forward. 2. In agile development, a spike can be represented as a product backlog item who primary output is the knowledge obtained by performing the spike work.)
Maybe you should create a custom field, maybe a custom sub-type to specify the Story type of your Story (US or Spike), or use a naming rule or anything else.

The Spike will refer to your Story Creation process and the User Story to your Story Development / Testing process. Obviously you should like the Spike(s) and the User Story(ies), it avoids the change ticket, you keep the history, and it is possible to reopen an issue if needed.
To have both burn down chart, I think you should use two different Scrum board (based on Spike and US).

Hope it helps.