Skip to main content

Subtask Estmiation

Last post 05:49 pm February 18, 2021 by Daniel Wilhite
5 replies
01:23 pm February 16, 2021

In my team we are creating subtask for most of the stories eg Development , Unit test or any other as required by the team and estimation is provided for subtask only. On daily basis team update the time spent.

1.Is there any issues in the way that we are following if so please update

2. Estimation for the story ie.subtask estimation is done before sprint is calculated. If in case a new subtask is created and estimated after sprint is started will it affect the sprint scope by any ways please update.


01:37 pm February 16, 2021

The only purpose of estimation is so a team can get its arms around how much work it can take on in a Sprint, so a Sprint Goal will then be met. All else reduces to matters of value and empirical process control.

Is your team delivering valuable work of immediate release quality every Sprint, and are they achieving their Sprint Goals?


04:52 pm February 16, 2021

Is there any issues in the way that we are following if so please update

Scrum doesn't forbid estimating sub-tasks or require it. Do the Developers doing the work find the sub-task estimates helpful? What problems has this solved for them? If there isn't any value added for the Developers, might it just be a waste of time? Perhaps time could be spent focusing on the Sprint Goal rather than sub-task estimation if there isn't any value.

Estimation for the story ie.subtask estimation is done before sprint is calculated. If in case a new subtask is created and estimated after sprint is started will it affect the sprint scope by any ways please update.

As mentioned by Ian, the focus should be on the Sprint Goal and achieving at least one valuable Increment by the end of the Sprint. Excpect that the Sprint Backlog should emerge and change throughout the Sprint, as more is learned. In complexity plans are never perfect. Thinking that your plan will be perfect upfront isn't realistic and is why empiricicsm is so important. It's Scrum's DNA. Help your Scrum Team embrace uncertainity and to respond to changes.


12:08 am February 17, 2021

[1] it is better to create the sub task before the sprint start

[2] If that is not possible if the user story was estimated correctly and all the sub-task stories sum is equal or less then user story story points initially identified during user story backlog refinement/gromming or sprint planning, then it will not impact the burn down chart in the end of the sprint.


04:59 pm February 17, 2021

@Vijay

[2] If that is not possible if the user story was estimated correctly and all the sub-task stories sum is equal or less then user story story points initially identified during user story backlog refinement/gromming or sprint planning, then it will not impact the burn down chart in the end of the sprint.

I only do story point for main story and not for subtask. Subtask is for easier split up of the task that developers are going to do and it helps them to come out how much time is required for story completion. So it helps me to judge how much is the developer occupied for a given sprint.

@Chris Belknap - By providing subtask the dev. can understand what they are going to do and how much time is going to take for story completion.

 

@Ian

Is your team delivering valuable work of immediate release quality every Sprint, and are they achieving their Sprint Goals?  Not 100%  but 90% they are delivering valuable work


05:49 pm February 18, 2021

I only do story point for main story ...

So it helps me to judge how much is the developer occupied for a given sprint.

Those two statements sound like something a Project Manager would say.  Unless you are a developer you shouldn't be participating in the story pointing and even then you will be only one person involved.  Why do you need to "judge" developer occupancy in a sprint?  In Scrum, all Developers are fully occupied by Sprint activities since the entire team is responsible for the work. 

Subtasks are useful for some people but not for all.  And if you are being successful in your Daily Scrum, everyone should know what the others are doing.  That is the purpose of the event.  Too often I see teams try to use subtasks as a way to circumvent the discussion and planning that the Daily Scrum is created to provide. As for estimating time and then updating that time, is it really useful?  How often have you gone back to look at the data collected for those subtasks as a means of improving?  If the answer is zero, then you are wasting your time updating the information.  And if you say "we do it all the time" I would ask what you are getting out of it?  Because every time you do an activity you learn something that will improve your ability to do it again.  So the actual time you spent last time will most likely change for each subsequent occasion that you repeat the same work. 

Software development practices evolved to make teams have more agility by looking at practices used in manufacturing.  Lean manufacturing practices were adapted to software development activities to reduce the wasted efforts undertaken by software development organizations.  If your subtasks and the methods you use for them are not providing benefit or are creating work, you should really question whether they are worth continuing.   Your original question and your response does not indicate whether the team feels that that there are issues with your practice.  And ultimately the Scrum Team are the only ones that can provide such an answer.  So ask them how they feel about their current practices, whether they feel there need to be changes, and what are those changes.  


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.