Print

Print


Thanks, Bob.

 

I’m definitely an advocate for alternatives to formal story writing.  On the projects I’m on, we will only write stories when the unit of work can be formally tested by our QA staff.  Formal story writing forces us to provide an Accepted Criteria value, which QA relies on to ensure the story can be successfully reproduced and tested.  The model we use to determine the Accepted Criteria is “Given-When-Then”.  QA can integrate properly formatted tickets into their regression test workflows with automated testing frameworks such as Gherkin.  Even the G-W-T model can be made more efficient. In many cases, we use “Given-Then” success factors. In other words, to be successfully reproduced, a condition (“When”) is not always necessary.

 

Conversely, when we have system-level and infrastructure tasks, investigative tasks, or project activities involving planning, we deliberately categorize the work as “tasks” instead of “stories”. As noted above, tasks are distinguished from stories because they do not need to be peer reviewed or formally tested by QA.  Significantly less effort is required to write an “Action/Expected Result” ticket than a formal agile story.  “Task tickets” significantly reduce the amount of team consensus that would otherwise be allocated for writing thorough and complete stories, as well as the story grooming that would take place in a separate ceremony. Task tickets do not need the same level of group scrutiny when it comes to estimation since a majority of our task-level tickets are usually limited to one or two people. Perhaps this is different in other projects here? By not having to write formal stories all the time, we can allocate any saved meeting time towards more useful group discussions/activities.


We have not consciously adopted the FDD model for writing task-level tickets, but it appears we naturally gravitate towards its principles by incorporating the most important aspects of any planned work, which is “what” the action is and its expected result.

 

Just our experience so far and two cents!

 

 

From: Agile at Library [mailto:[log in to unmask]] On Behalf Of Shirley, Robert L.
Sent: Tuesday, August 22, 2017 10:34 AM
To: [log in to unmask]
Subject: Not Everything Needs to Be a User Story

 

https://www.mountaingoatsoftware.com/blog/not-everything-needs-to-be-a-user-story-using-fdd-features

 

 

Here’s an older article by Mike Cohn where he talks about how to handle user stories that are more focused on back-end features and do not have custome-facing components. He advocates for a different syntax for these stories, leveraging FDD as example. Instead of saying “As a developer…” or “As a product owner…” say something like  “Merge the data for duplicate transactions” (<action> the <result> <by!for!of!to> <object>)

 

What does everyone think of this approach? How do you handle these types of user stories in your backlog?

 

 

 

 

Thanks!

 

Bob Shirley

Team Lead, PMO

Library of Congress

(202) 707-0166