Skip to main content

Scrum - Planning and Decomposing Task

Last post 05:06 pm April 6, 2018 by Filip Łukaszewski
7 replies
06:59 am March 29, 2018

Hello All,

I am working a new organization since 1 month and we are trying to implement all of the Scrum best practice to this organization. I had a previous experience as well but according to this condition of this organization I would like to consult you something.

1) For my previous organization we are planning team capacity according to the focus factor which is equal to around 6-6.5 hours and we also changed Jira time like as 6-6,5 hours. But in this organization Jira working based on 8 hours effort and for some reason it seems we could not change it. So how can we handle this issue ? Team putting their worklog on Jira and we will also initiate to tracking Burndown chart. But due to focus factor that might be challenge. I will be appreciate if you can help me about to find a solution.

2) We decided to use also story points and this is totally new as well for this organization. We have a plan to estimate the main task as a story point by the development team and we would like to give them a chance to decomposing the task by themself. The rule is the task estimation will be not more than 1 day. To convince them what is the main reason really to decomposing task and estimate them like a hours.


3) The last question is, per my opinion we should plan and estimate all of the PBI during the Sprint Planning and Backlog Grooming. But some of them think that we might give our estimation and replan the PBI during the Sprint. Is that really practicable ?


09:52 pm March 29, 2018

Semih, a few comments/questions regarding your inquiries:

1)  What is the hour input into JIRA used for?   Can you tie your burndown chart to story points instead of hours?   In my personal opinion, hour-tracking is wasteful in Scrum, as a story is only "done" when it meets Definition of Done, not when the number of hours allocated for it is reached.

2)  I'm unsure what you mean when you say that you estimate the main task as a story point.   The entire story should be relatively-estimated, not the individual tasks.   

Task decomposition is a good thing, as it provides the team greater clarity into story complexity and effort, but my advice would be to simply associate all of the tasks for a story, with no task estimation.   There are others though who favor task estimation in hours, and perhaps they can provide their reasoning.

3)  It is a good (and rather mature) practice for a team to estimate an entire backlog.   This is a very good practice, as it gives the PO some level of insight into the size of the items in the backlog, and helps then to plan future sprints.

Estimations can be revised all the way through sprint planning if needed, based on new information gained by the team.   However, at no time should any item estimation be altered once it is forecast by the team in a sprint and the sprint has begun.   A team may identify a different solution during the sprint that is simpler and/or quicker to implement, but allowing the estimate to change based on what happens during a sprint deprives the team of reflecting on how they estimate, and what potential areas they should consider to improve their accuracy.

Keep this in mind, and this is extremely important.   Relative estimating (story points) are for planning purposes only!   They exist simply to help the Development Team and the PO assess what can be completed in a sprint.   They are a guideline at best.   Once the sprint starts, story points are meaningless outside of their use in burning down sprint progress by story completion.

Hope this helps.   Good luck.

06:54 am April 3, 2018

Hi Timothy,

Thanks for your valuable response. Let me clarify some of the points that you asked.


1) Currently it is 8 hour for our organization due to some of the budget calculation. But we realize that planning like as a 8 hour is not realistic therefore we use some focus factors and meanwhile Scrum is also really new for this organization. Theerefore the main problem is we are making our planning via 6 hours but we have a missing 2 hours in Jıra.That is why we might need a solution to handle this.

01:25 pm April 4, 2018

Theerefore the main problem is we are making our planning via 6 hours but we have a missing 2 hours in Jıra.That is why we might need a solution to handle this.

If I understand correctly, you're saying that your main problem is that the tool you are using (JIRA) doesn't support your current planning practices?   That isn't really a problem with Scrum/Agile, is it?   Perhaps you need to investigate other methods to account for time spent?

A very common analogy with planning for a full 8-hour day is to look at a highway.   Is it better to ensure that each part of a highway is being used 100% all of the time, or does a highway work better when there are gaps between cars on a highway?   Supporting 100% time utilization hurts flow (i.e. - traffic jams), is not reflective of reality, and is often a futile exercise.   Planning should account for "slack" that both promotes greater flow, and allows for the unexpected to be managed efficiently.


07:25 pm April 4, 2018

the main problem is we are making our planning via 6 hours but we have a missing 2 hours in Jıra

Why is this a problem? If the team plan x hours of work for an item, and complete y hours, then x-y will remain. The number of hours which are thought to be in a working day is irrelevant.

11:08 am April 5, 2018

Because of in this organization budget will calculation according to the 8 hours and they refer to Jira worklog.. The first thing that I would like to change is 8 hours is really high for capacity planning and therefore we would like to calculate focus factor.Due to I have no any velocity information for our first planning we calculated team capacity as a 6 hours.. But before they put their worklog in Jira as a 8 hours and that is why from now on they will put their worklog as a 6 hours.. But there is a 2 hours missing in Jira and that is why I am searching a common solution for this issue.

Another question is all of the scrum meetings include focus factor or should we also exclude the scrum meetings after the calculation that we include focus factor.. I mean shoudl we also take out the scrum meetings from the 6 hours ?

09:38 pm April 5, 2018

I think that the focus ought to be on the value which is delivered by the team, and not on the time spent by individuals.

It sounds as though:

- organizational billing and accountancy hasn’t changed to support team-based agile development, and

- an ostensibly “agile” tool, which happens to offer a limited time-tracking capability for developers, is being used as a crutch.

05:06 pm April 6, 2018

" I mean shoudl we also take out the scrum meetings from the 6 hours ?"

Yes, we the team forecasts what it can accomplish it should take into consideration time about to be spent on Scrum ceremonies, and backlog refinement process, that will, short-term wise (sprint), reduce team's capacity.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.