Is there any way to have SubTask story points roll up to the Issue? Not sure if this is possible after reading some answers on the forums but would like to double check before making my mind up.
Why on earth would you complicate matters by having two different ways of estimating effort when a key in SCRUM is to keep things simple. The name "story points" shouldn't have to be restricted to issues of type "Story" just because the names are similar. A story is the sum of it's sub tasks and the story points of a "Story" should be the sum of its sub tasks story points.
Having story points at sub-tasks is conceptually wrong. Stories are estimated in story points for helping the overall release planning by the product owner, while the sub-tasks estimates in Efforts (remember it is recorded in Original/Remainining estimate fields) and sprint burn down drawn to see how the sprint is progressing by the team.
Just like story points of one's team are incomparable with story points of other team, so are the story points of tasks (and sub-tasks) with user stories.
story points of tasks are only assigned during sprint planning meeting to judge whether we can fit tasks into a sprint.
The velocity of a team is measure in product backlog's story points.
I'm sorry, but that doesn't make sense to me. Why should there be two different estimation paths?
The whole point of scrum is to not limit the team to temporal values, but rather points of complexity. Therefore, there should be enough flexibility in jira to allow for sub-tasks to story - points roll-up.
The Sprint itself is already timeboxed. So why should the scrum team need to time estimate their sub-tasks?
The burndown chart should show how many points the team has accomplished in any given Sprint, not how much time they plan to spend on a given task.
Is there anyway to add SUM function on the story level for it's sub-tasks?
stories are not the sum of their tasks, just like your activities at home aren't the sum of your to-do list.
Subtask estimation is honestly only useful to make sure the team discussed the subtask. estimating it in something easy like 2,4,8 really is just a relative value to see if the team is aligned. if someone thinks something will take a tiny part of the day and someone else thinks that same thing is a whole day of work - the number doesn't matter, what matters is the fact that the team discusses the discrepency.
stories in points, subtasks in "hours", and burn down by subtasks in sprint so the burndown actually is useful to the team. what you shouldn't do is use those hours as a reporting mechanism or ever say to someone we have 'x' hours remaining. reporting should only be done for user stories, never tasks - tasks are for the team. User story points give relative velocity. subtasks are just the relative effort "to do" list of the team.
the only reason to even use numbers is so you can reduce subtasks as they progress so you can get an actual in sprint burndown that is useful to the team.
It's interesting that five years later this is still a topic of discussion.
I had a story of GitHub Transition (from SVN). There were five tasks under it, for the different types of components to be transitioned. Each task was owned by a different area. The tasks were estimated, the story was not, but we wanted to track the overall progress of the GitHub transition. I can understand how someone might be interested in the points rolling up to the story, as it's something MS Project does.
You can't do this, regrettably, as some teams prefer sprint planning in time units, others in story points, and a clunky tool should be not informing that choice.
A workaround is to pick an arbitrary unit such as hours or days to represent story points at the sub task level, and then you can get some idea of completion and progress without having the overhead of double entry.
"A workaround is to pick an arbitrary unit such as hours or days to represent story points at the sub task level" -> imo this is bad practice, I would never try to convert SP into minutes/hours/days and vice versa. SPs are for complexity not for duration of a task/story. Sorry if I'm wrong, but this is my opinion ;)
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs