2

Let's say we have a good User Story with Acceptance Criteria and Definition of Done. But the Story is too big and needs to be split into tasks.

The team only uses hours for estimating the backlog items.

What do you do in this case - do you estimate the User Story and the Tasks?

If all tasks are estimated, what estimation does the User Story have (none?)?

Improve this question

2 Answers 2

Reset to default
1

Assuming you are using Scrum, if the story is too much to do in a single sprint then it should be split into new stories (not "tasks") each with their own estimate and acceptance criteria. In that case the original story is no longer needed but the new stories might be labelled or grouped together as an "epic" that spans more than one sprint. Epics don't need estimates of their own as they are simply done whenever there are no more associated stories to complete.

Within a single sprint it is common to break down each story into tasks but this should normally be done for the sprint backlog only; that is, after the story has already been accepted for the sprint and the team has agreed that it is achievable within the sprint. That being so, it's not usually necessary for the Product Owner or other stakeholders to see estimates for individual tasks because the sprint goal is already defined and agreed.

If your team do find it helpful to estimate tasks within a sprint then I suggest you leave the estimate for the story unchanged. I would recommend that in the interests of transparency and simplicity you adopt a policy that a partially complete story does not count towards the sprint velocity at the end of the sprint. Only a completed story counts and in that case the original story estimate is what matters. Measure sprint velocity based on the estimate you agreed before or during sprint planning rather than based on any estimates the team assigned to individual tasks.

Improve this answer
4
  • 1
    Thank you @nvogel. I was referring with Stories and Tasks to Jira, so it was a little bit confusing. A Jira Task is at the same level as a Story. Therefore, if a Story is break down into "work tasks" it's better to use Jira Sub-Tasks and not Jira Tasks. Of course, when a Story is to big for a sprint, the Story is split into smaller Stories. After that the developers break down the story into "work tasks" (so called Sub-Tasks in Jira).
    – reneton
    Commented Jun 7, 2021 at 9:14
  • OK. Glad I could help. Personally I use Jira Stories as stories and Jira Tasks as tasks but thanks for the clarification.
    – nvogel
    Commented Jun 7, 2021 at 9:23
  • So you don't use Sub-Tasks to break down the Story into "work tasks"?
    – reneton
    Commented Jun 7, 2021 at 9:42
  • If you use Tasks instead of Sub-Taska and you only esrimate the User Story, you will have unestimated items in the backlog and then the Jira reports are not accurate.
    – reneton
    Commented Jun 7, 2021 at 17:41
0

  1. If you use JIRA, then you need to create the story, and team need to create subtasks into that Story.

  2. In my case i use JIRA cloud, and the team estimate (in hours) each sub-task and asign the responsable in each sub-task.

  3. I don´t add hours to the Story, just it´s subtasks.

  4. I get in "reports", the quantity of hours team will be dedicate, grouped by developer´s name. I can see the amount of hours, and the Stories associated, and even i can see their subtasks.

  5. I see the amount of hours for the sprint, and if it fit into 2 weeks duration, and the team agreed with that, then I have my sprint ready to started.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.