Writing the Granularity of the Task - Where?

Question

The following is from JIRA:

User stories are sketched out by the product owner, then the full product team collectively decide the more detailed requirements.

These are the granular pieces of work that help define the implementation items for the story and the upcoming sprint. In the above example, there are a set of tasks required to make the account feature work: database changes, new server logic, as well as new user interface components. These tasks should be fleshed out during estimation of the user story and linked in the team's issue tracker.

But I thought User Stories were written out like As a <type of user>, I want <goal> so that I <receive benefit>. I am a bit confused, where do I write the granularity (the lower-level individual tasks that are associated with developing the item listed in the User Story).

Also, do we not use acceptance criteria in JIRA?

Answer 1

Jira is just a tool, don't let it dictate your process. Instead, decide how you will do your work and then figure out how to make Jira work to your needs.

Acceptance Criteria: You should always use these. They are critical to an effective User Story. Without the AC you don't have a way to measure if the customer need is met.

Tasks: Jira taxonomy supports Tasks under User Stories. Remember that Tasks are not User Stories and don't need to follow the "As a.." format. Tasks are the development team breaking down the work to complete the User Story. For example, if you're baking a cake you could have a Dry Goods, Wet Goods, Baking, Serving.

Answer 2

User stories

They are requirements from user's perspective. As team discuss the requirements, they will identify the various tasks that need to develop and deliver it.

Story and Tasks

You may find it easier to break down a story into tasks/sub tasks to represent the UI, business logic, database tasks if you are following a layered architecture. Or perhaps one or more stories/tasks for different components/service in a microservice architecture.

In Jira, you could do it many ways. For example, (a) link tasks to the main story (b) create a theme/epic and link all the stories to it to show the association and so on.

Technical stories need not be verbose, just enough documentation would suffice.

Acceptance Criteria (AC)

AC is important especially if there different conditions to meet in a story/requirement, as you will need to elaborate them in your AC field so that TDD, BDD and unit testing can benefit from it. This way you make sure the system you develop satisfy all the requirements from the user/customer.

Answer 3

User stories and tasks are different things.

The user story and acceptance criteria answer the who, what, why questions and describe the work in terms of business value to a specific user.

Tasks are implementation details that answer the how questions.

Most tools like Jira, Rally, VersionOne have multiple ways of storing user stories, tasks, and acceptance criteria.

You may have a totally flat item in these tools with free-form text describing the different entities or the more common format of a "Story" entity that contains the the user story and AC details, and children "Task" entities that contain the implementation steps. You may want to reference the Jira help utility to understand and see examples of how the different entities in Jira are intended to work.