We can certainly bake it in the project creation process.

We also need to discuss the importance of story points. I see them as a project level tool, and they should not be used as a project reporting or status metric. 


On: 23 August 2017 10:06, "Engratt, Steve" <[log in to unmask]> wrote:

I can confirm we are tracking points through Tasks in JIRA, and you’re right--it’s a deviation from the default config.  Would we need to reach a consensus on making this a permanent part of a default project template, or is this something we can bake into our default project templates?

 

 

From: Agile at Library [mailto:[log in to unmask]] On Behalf Of Nibeck, Mike
Sent: Wednesday, August 23, 2017 7:53 AM
To: [log in to unmask]
Subject: Re: Not Everything Needs to Be a User Story

 

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