Should we rather estimate sub-tasks than the story itself on Jira?

This all seems excessively complicated to me.

Product scope is a different thing to the forecast of work for meeting a Sprint Goal. The estimates afforded to one therefore ought to be quite independent of the other.

The story points used to frame the scope of a Sprint are not a function of any tasks that may be planned...or vice-versa. Tasks for meeting the Sprint Goal may reasonably be planned in terms of hours. They are a different thing. There is no need for those task estimates to correspond to story points at all.

In fact, tasks don't really need to correlate to User Stories in the first place. Remember that the objective is to achieve the agreed goal, not to "deliver" backlog items like stories. Those items are just a forecast of product scope that is likely to prove relevant. This is not always obvious when using electronic tools because they can force you into thinking there is a one-to-many relationship between stories and tasks. I suggest the time is right to take a step back from these tools in order to free your thinking.

Posted By Ian Mitchell on 28 Sep 2016 01:04 PM
This all seems excessively complicated to me.

What in peculiar?
My proposal seems a more simple approach than the one you're describing. If I got you right we should estimate both stories (in SP) and sub-tasks (in hours) whereas we only estimate the former as of today.
My opinion was to translate these SP to the sub-tasks so that we don't have to estimate these sub-tasks independently. There would be no estimation round needed in our sprint. Not that I've anything against your proposal per se, but I see it more complex than mine.

Do you think it's a bad idea to actually use DoD as a way to streamline our workflow? If yes, how do you make DoD more "visible" and "real" to the team?

Would you "decouple" a story from the tasks we need to do to achieve it in terms of estimation?

Thanks! :)

> My proposal seems a more simple approach than the one you're describing.

What I'm describing isn't a proposal at all. I'm describing the way scope estimation and sprint forecasting works in Scrum. If you believe that you have identified a simpler or more rational approach, then you should take it to the team and find out if they wish to try it. It may indeed be an improvement over the present situation. Let us know how you get on.

I've attended two certification courses, have the PSM I and I wasn't aware that estimation should theoretically go further than giving SP to stories. Eventually that's something not clear at all from both certifications. The video tutorials on sprint planning always mention planning poker on this on the story level and nothing more.

I'm totally up for a change though don't get me wrong on that.
Would be nice if you or somebody else could clarify the followig:

How to make DoD more real if not through sub-tasks of a story?

How to decouple "tasks" from small user stories on Jira concretely?
Do I need to create tasks (estimated in hours) and link them to one user story (estimated in SP). In the end, it's likely than 99% of the time the tasks will be very close to our DoD anyways.

> ...I wasn't aware that estimation should theoretically go further than giving SP to stories

The Scrum guide says: "At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed". The Sprint Backlog is a forecast of the work needed to accomplish the Sprint Goal. It is not a mere subset of the Product Backlog with the associated estimates. It is a plan of the work that the team expects to actually do to meet the Goal. That Goal should provide coherence to the effort and give purpose to the Sprint.

Scrum is a framework with minimal requirements. There's nothing to stop a team from assuming that estimates (e.g. story points) given to selected PBI's can be used to adequately reflect the work remaining in the Sprint to meet the Goal. They can always try it, and find out how well that assumption holds. If that proves to be the case, then clearly there would be no need for any tasks to be estimated at all.

> Would be nice if you or somebody else could clarify the followig:
>
> How to make DoD more real if not through sub-tasks of a story?

I don't see any problem with capturing a DoD as tasks to be accomplished in a Sprint. I think it is an excellent idea for making it real. However, you must remember that of course there may be other tasks. Also, remember that the DoD properly applies to the increment rather than to the PBI's which were originally planned into the Sprint.

The Scrum guide says: "At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed".

And that is the case right now unless I'm wrong.
We're using SP and from sprint to sprint we use to plan the next one.
Sometimes it can be that some stories are underestimated/over and that the burndown isn't so smooth (hence my question how to make this). On the other hand we're about +/- 20% accurate with the original estimate which isn't so bad but I'm trying to figure out how to reduce this to +/- 5%.
For instance it's very often though that a story has one or two tasks left and that we have to postpone it to the next sprint. The estimation will be burned down on the sprint n+1 though. Had we estimate every task this would not feel this way.

I think it is an excellent idea for making it real. However, you must remember that of course there may be other tasks

It really helped a lot actually when we came up with this indeed. We've got three sub-tasks template depending on the "context" of the story, and we always refine whatever sub-tasks seems to be missing or superfluous together during planning.

Also, remember that the DoD properly applies to the increment rather than to the PBI's which were originally planned into the Sprint.

Indeed, our strategy so far it's too have several sub-tasks depending on the "context" of a story.

Hum, it doesn't help me decide whether I should try my original idea or not. Any other input would be appreciated! :)

> And that is the case right now unless I'm wrong.
> We're using SP and from sprint to sprint we use to plan the next one.
> Sometimes it can be that some stories are underestimated/over and
> that the burndown isn't so smooth (hence my question how to make this).
> On the other hand we're about +/- 20% accurate with the original
> estimate which isn't so bad but I'm trying to figure out how to reduce
> this to +/- 5%.

That would suggest the simple case is not appropriate in your situation.

In other words, in your case it isn't fair to assume that the estimates (story points) given to selected PBI's can be used to adequately reflect the work remaining in the Sprint to meet the Goal. You've tried it, you've found out how well that assumption holds, and it doesn't. Therefore you need to look at estimating your plan of work, such as tasks, separately. Many teams do this in hours and elicit a sprint burndown in task hours.

> For instance it's very often though that a story has one or two tasks left
> and that we have to postpone it to the next sprint. The estimation will be
> burned down on the sprint n+1 though.

From your PSM training, what do you think about the idea of allowing tasks to roll over into the next Sprint? Aren't those tasks planned to meet the goal of the current one?

> it doesn't help me decide whether I should try my original idea or not.

In Scrum, who actually would make this decision?

I really like this interactive talk I'm having with you Ian! Thank you so much for your time!

That would suggest the simple case is not appropriate in your situation.

I do hear you but I want to make our current status quo clear though.
We're not perfect to predict what will happen in a sprint (the reason why I'm here) but we're quite accurate to predict mid-term to long-term scenarios. The fact that one or two stories out of 15 roll over a sprint has very few influence on the mid-term forecasts.
Over the last two years we've been able to derive a release date with one-month accuracy about 6 months in advance, do you see this approach as inaccurate?
Given we're able to tell our Mgmt that we'll deliver this in XX months should we invest much more time in estimating every task? Is that really time and effort well spent? Must tell you I'm not entirely convinced.

From your PSM training, what do you think about the idea of allowing tasks to roll over into the next Sprint? Aren't those tasks planned to meet the goal of the current one?

We do not always formulate an explicit sprint goal. I'd say the PO and us make sure of the overall consistency and "iterativity" of the sprint and that we do not have multiple focuses.We nevertheless don't explicitly formulate this into one sentence but i'm considering changing this and see how it goes.
As for the one or two stories that are at the end of the tail of the latest sprint, it surely never pleases us but this would imply we are able to predict perfectly what will happen two weeks in advance. That's just not something we can't achieve every sprint (on average we're within 80% accuracy as I mentioned) and I do not understand why would the sprint goal has an influence on this?

28 Sep 2016 07:42 PM Correct Answer?QuoteReplyAlert
> And that is the case right now unless I'm wrong.
> We're using SP and from sprint to sprint we use to plan the next one.
> Sometimes it can be that some stories are underestimated/over and
> that the burndown isn't so smooth (hence my question how to make this).
> On the other hand we're about +/- 20% accurate with the original
> estimate which isn't so bad but I'm trying to figure out how to reduce
> this to +/- 5%.

That would suggest the simple case is not appropriate in your situation.

In other words, in your case it isn't fair to assume that the estimates (story points) given to selected PBI's can be used to adequately reflect the work remaining in the Sprint to meet the Goal. You've tried it, you've found out how well that assumption holds, and it doesn't. Therefore you need to look at estimating your plan of work, such as tasks, separately. Many teams do this in hours and elicit a sprint burndown in task hours.

> For instance it's very often though that a story has one or two tasks left
> and that we have to postpone it to the next sprint. The estimation will be
> burned down on the sprint n+1 though.

From your PSM training, what do you think about the idea of allowing tasks to roll over into the next Sprint? Aren't those tasks planned to meet the goal of the current one?

In Scrum, who actually would make this decision?

The SM is here to mention that we are not estimating properly and I should facilitate discussions on this topic while coming with my own proposal?

Damn sorry for the last part. How come I cannot edit my answer?

In Scrum, who actually would make this decision?

The SM is here to mention that we are not estimating properly and I should facilitate discussions on this topic while coming with my own proposal?

> Over the last two years we've been able to derive a release date
> with one-month accuracy about 6 months in advance, do you see
> this approach as inaccurate?

In Scrum, it's the Product Owner who would forecast any future release dates from the empirical data provided by the team. Therefore it's up to the PO to decide whether or not the approach is sufficiently accurate.

> Given we're able to tell our Mgmt that we'll deliver this in XX months
> should we invest much more time in estimating every task? Is that
> really time and effort well spent? Must tell you I'm not entirely convinced.

The purpose of estimating tasks is not to appraise stakeholders (such as management) about the deliverables of future sprints, but to show whether or not the team is on course to achieve the current Sprint Goal. Being able to provide that forecast, to show the work remaining in the Sprint, and to evidence that control, is usually time and effort well spent. You've already recognized how desirable it is to have a smooth sprint burn rate.

> We do not always formulate an explicit sprint goal.

If you don't formulate an explicit Sprint Goal, then why sprint at all? What purpose does sprinting then serve? What makes the batch of work selected for that Sprint coherent, and worthwhile handling as a batch?

> I do not understand why would the sprint goal has an influence on this

Because the objective of a Sprint is to achieve the agreed Goal, not to "deliver" backlog items like stories. Those items are just a forecast of product scope that is likely to prove relevant to the Goal.

Once a sprint ends, any undone work should be evaluated in the Sprint Review. If it is still relevant to the Product it can be re-estimated on the Product Backlog. It may then be planned in to a future sprint along with other work that gives coherence to a new goal. There can be no roll-over of work from one sprint to the next, because each sprint brings a new planning session, with a new goal and a new forecast of work for achieving it.

Thank you so much agai Ian! Too bad you're the only one but I'll rely on what you say.

Here are two action points:

I'm gonna trigger the topic Sprint Goal to our PO and we will implement it.
I agree a sprint goal helps the sprint to be purposeful, consistent and focused but I don't believe that having no sprint goal implied that we're doing 4 different topics at once which aren't relevant to each other and invaluable to our product. So yep, might not be the main impediment in our team here.

I will also trigger the discussion as of how to estimate our tasks in hours and see how it goes.

I want to experience a bit and get out of the comfort zone here.

PS: Damn that forum is so old-fashioned and static for years, not a good image of what I would expect from a website like scrum.org. Move on guys! :) https://www.discourse.org/

Personally, I am a big proponent of relative story estimation. While I also find value in defining the tasks for a specific PBI, I do not advocate what I consider a wasteful activity in estimating those tasks.

For instance it's very often though that a story has one or two tasks left and that we have to postpone it to the next sprint. The estimation will be burned down on the sprint n+1 though. Had we estimate every task this would not feel this way.

It seems task estimation in your example would only be done to appease the team and consumers of your sprint metrics in order to "make things look good". I would simply ask why that should be important to you, your team, or your organization? The end customer does not care how many of the tasks are completed for a specific story, only that the story has been completed and delivered.

In addition, removing the "reward" from completing "most" of the tasks for a PBI would hopefully stress to the team the importance of conpleting the entire story according to the DoD.

Completely agree with Mr. Baffa on this one. All practices and metrics must be understood and valuable.

Getting back to you guys I must say I kind of disagree with Ian's point after all.

I have interviewed 3 other teams who stopped estimating sub-tasks per hours because it didn't help but to waste time in plannings. Every team came to the conclusion that it didn't bring anything but a smoothed burndown... yet didn't avoid the problem of over/under commitment.
There's one team left who's estimating stories in SP and each of their sub-tasks in hours... and looking at they burndown it certainly looks very smooth but they seem to over-commit all the time. Therefore as it's been stated here and there I wonder what is the point of spending so much time estimating something.

Imho estimating sub-tasks in hours is absolutely not the correct entry point to our problem. We just need to get better at slicing stories and I have to push the emphasis on this for the next sprints.