When using story points, a task that has been estimated as 1 is the most "trivial"/simple in terms of complexity and definitely fits in a sprint.
Lets assume that a task of complexity 13 and above is too big to fit in a sprint.
Now lets also assume the case that we have a task task/story that can be broken down to 13 subtasks that all the team agrees each is of complexity 1 story point.
How do we estimate the size of that parent task? Is it 1 story point? I.e. since all the subtasks are of size 1 so is the parent ticket? Or is it 13 i.e. the summation of all the 13 subtasks of size 1 story point.
I could claim that this task can be completed in a sprint because its subtasks are of such a low complexity but in that case we have a task of size 13 that the original premise was that it does not fit in a sprint.
So what is the proper way to estimate the size of this/such task(s)? Generalising it for cases that the subtasks are of varying complexity: is the parent task's size the size of the most complex subtask or is it the sum of the subtasks?
-
Tasks are really just reifications of your Definition of Done for a story or epic. This is therefore a JIRA-ism and you’re letting the tool drive your process. If tasks are more complex than binary done/not-sone checklist items, they are really predicate stories to be integrated, not simply roll-up items that will sum to your current story’s estimate.– Todd A. Jacobs ♦Commented Nov 23 at 1:38
4 Answers
When a story is too big to fit in a sprint the approach is to try and break it down into smaller stories. Note that this has nothing to do with tasks.
In the event that a story cannot be broken down small enough to fit in a sprint then the team will likely have to accept that it will take more than one sprint. This is not a good situation and the team would usually take that up in their retrospective to think about better ways of breaking stories down.
The reason we don't follow the approach you describe is that in Scrum we are trying to deliver a valuable increment every sprint. If we start estimating using story points at the task level then it defeats the whole object of using story points.
If you still want to follow this approach you describe then the best thing to do would be to drop the use of the term "story points" and just estimate the tasks in hours.
-
Lets say the task is "Enhance service web page with upload functionality of user data". That is basically just a) add a button in a page b) on press pass a file to the backend api c) on backend expose an endpoint to accept the file d) save the file to the db. You can see it as a simple task for a full stack developer or it can be one JIRA task with 3 distinct JIRA subtasks. Are you saying that 1) only these subtasks should be estimated and put in the sprint and use the parent task with the description as a placeholder or 2) not have the parent task at all?– smithCommented Oct 3 at 18:06
-
To me (2) sounds wrong because otherwise the (3) subtasks on their own don't make sense. It is that parent ticket that has the logical/business context. So what do you suggest?– smithCommented Oct 3 at 18:06
-
"Enhance service web page with upload functionality of user data" is a pretty good user story. Estimate it in story points as a whole. If the amount of story points suggests it is too large to fit in a sprint, have a think about how the user story might be broken down into two or more smaller user stories. Note that I'm not talking about tasks here; each user story still needs to deliver real customer value. Commented Oct 3 at 22:14
-
But if the team does not have a full stack developer the story will be worked on by the front end developer and the back end developer. Additionally when discussing about the effort these 3 separate pieces of work (FE changed and backend changes) are taken into account separately. So I am confused how can we track the progress by just having 1 ticket with the estimation. E.g. if the backend work includes some complicated processing logic and might have dependencies to update the storage the story could be in progress for a while the front end part is complete.We can't track this with 1 ticket.– smithCommented Oct 3 at 22:32
-
Great question! When breaking down a larger task into subtasks, it's essential to consider that even if each subtask is simple (1 story point), the overall complexity of the parent task isn’t necessarily the sum of the subtasks.
The parent task's size could be interpreted in two ways:
Sum of the Subtasks: If you view each subtask as contributing to the total effort, you’d sum them up. So if there are 13 subtasks each estimated at 1 story point, the parent task would be 13 points. This makes sense in terms of effort but might contradict the idea of a task over 13 points not fitting into a sprint.
Most Complex Subtask: Another approach is estimating the parent task based on the most complex subtask. This method avoids overcomplicating the estimate by not summing up small tasks unnecessarily and gives a more sprint-friendly estimate.
In practice, many teams will sum the subtasks, but keep an eye on how that total aligns with the sprint's capacity. Even though the task's total is 13, if all subtasks are manageable within the sprint, it could still fit. The key is balancing the task's breakdown with the sprint's goals and keeping it within scope.
Hope that helps clarify things! 👍
A story has story points, not subtasks. A story is to be completed in a sprint. Plus, story points are to visualize the complexity of a story, which means they can not be treated as "hours", which means you can not add them up to define the parent issue's (an epic for example) complexity.
So, in your case, using your wording, I can say that, if a task were to fit into a sprint, you would not need to break it down into small subtasks. If you broke it down into small subtasks to fit work into a sprint, then they should be treated as tasks from now on, not as subtasks. So, there's no need to sum the efforts of a subtask to find the effort of a task, just like we don't find the "total story point" of an epic.
-
I am not sure I agree. We can have a story e.g. add a new functionality that is supported by adding a button in a UI that accepts a file which uploads to a service and after validation and processing it is saved in storage. This is one story that can be broken down to a UI change, a DB schema change, a BE change and an API creation. All these are subtasks and show the progress of the parent task. So they could all fit in a sprint. Now are you saying to configure jira to only show those subtasks in the sprint view and use that parent task as a "place holder" without assigning an estimation?– smithCommented Oct 3 at 5:53
-
I am saying the opposite; your story "adding a button in a UI that accepts a file which uploads to a service and after validation and processing it is saved in storage." will have story points, but "UI change, a DB schema change, a BE change and an API creation" will not have story points. You should not compare a "DB schema change" to an "API creation". What we compare with story points is an increment of a feature, not a specific technical subtask. Commented Oct 4 at 9:25
-
How can we estimate the story (with story points) without breaking it down the effort? Also different devs can pick up these parts e.g. front end developer the UI changes and backend developer the backend changes. So I dont understand how can we track the progress if we just have 1 JIRA ticket/story "adding a button in UI that..." and estimating that– smithCommented Oct 4 at 18:02
-
Generally, a story is to be built by a single developer. If your team does not have fullstack developers, then you will need to create subtasks for sure, but the story points go to the story, not to the subtasks. Every developer will provide their own understanding of the complexity of the story as a story point. In the end, you don't provide story points to the subtasks. Commented Oct 5 at 8:46
-
If I understand correctly, there will be JIRA subtasks, each developer will provide their own estimation of the effort for their part i.e. front end work 2 story points, back end work 5 story points and the total effort will be assigned to the story and not the subtasks? is that what you mean? So the story will be total of 5+2=7 story points?– smithCommented Oct 5 at 17:28
Aligning on how your team(s) implement story points is critical to your success. Every company's approach is different but here is a success pattern I've seen a few times:
Story points are a way to estimate effort of implementing work. There are 3 inputs:
People's time: keyboard, research & collaboration time. These could be listed as subtasks (or not).
Complexity of work: multiple data types, conversions, interactions, etc. These could be listed as subtasks (or not).
Uncertainty & risk: how well is request defined? Is scope clear? Any dependencies?
The team needs to agree on what '1 point', '2 point', '3 point' stories, etc look like so they can refine/estimate the proposed work accordingly. If a PO estimates initially they should be sure to get the team's input before committing to delivery.
