Time tracking on subtasks vs. Points on stories.

[Gil]

My team estimates stories with story points (relative complexity), but when they do R&D on each story, they try to also estimate the subtasks in hours.

So the stories are high-level estimations, and the subtasks are level of effort (low-level estimation).

We have the development team and the testers estimate on story points separately and then we combine the points. So if testers estimate story complexity on 3 and developers on 5, then the story is 8 points.

The jira board is set to burn story points.

I'm not sure what is the "better" way of handling this since we also use to track hours on subtasks.

I'm a bit confused about how to best approach this in reporting.

Thoughts?

[Ollie Guan]

Hi @Gil ,

Story point estimation is generally done using poker estimates, and the entire Scrum team's joint participation in the estimation is an important practice, so I think the tester and development team should work together to make an estimate.

[Gil]

We do that together. We're all in a poker estimation meeting, the entire team at the same time. We just add up the testers and developers estimations, because both coding and testing have different complexities.

Yet, after the initial estimation we assign story leads and each story lead will work with 1 or more developer and they will do low level estimation - this is where they create the subtasks and estimate on hours on each subtask. We also readjust the story points if we realised it's more complex or less complex then initially thought.

All of this is done to provide better projection and accuracy, self-feedback on how we estimated initially, flag any issues that we didn't think of during the initial estimation and so on.

The testers do the same.

So what's the more correct approach? burn hours or story points?

[Ollie Guan]

Jira provides a variety of burn-down charts such as workload and story points. You can choose freely, but no matter how you choose, you need the team to define the story and the completion criteria of the task before the sprint starts. Here are some suggestions. for reference:

1. Select the story point as a burndown chart
The user story must be incrementally tested and completed in the sprint. After a user story is completed, the story point is burned out.

2. Select the workload as a burndown chart
At the completion of each task, the workload is burned out. If the roles of the team are clearly defined, this is an alternative way of burning.

Of course, you can also observe two burnout charts at the same time to track the progress of the sprint.