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?
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….
Software Engineering Manager
OCIO - Web Services
Library of Congress
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!
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?
Team Lead, PMO
Library of Congress