Print

Print


Agree, Storys are not the only bucks we should be using/ The only issue with using Task in Jira is that they don’t track Story points by default. That makes it difficult to track velocity of a team, something which we would like to do in the future. I believe we can add Story Points to a Task in Jira, but not sure…. 

Mike Nibeck
Software Engineering Manager
OCIO - Web Services
Library of Congress


From: Agile at Library <[log in to unmask]> on behalf of "Engratt, Steve" <[log in to unmask]>
Reply-To: Agile at Library <[log in to unmask]>
Date: Tuesday, August 22, 2017 at 12:53 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: Not Everything Needs to Be a User Story

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