Scrum - Planning and Decomposing Task

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.

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.

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.

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.

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 ?

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.

" 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.