Sharing storypoints in a task/story with others

[Imre Antalfy]

Dear all

Our team works in prototype plant engineering. For example, we build a hydrogen refuiling station in a 20 foot container with a team of at least six engineers. We find a lot of value with a semi scrum approach. I understand we should carry through scrum as a whole thing, but it was not yet applicable. Now we face an issue we can't find  a solution for. Here an example:

We have a lot of task which are worked on by at least 4 people. The task is in total 8 story points. I need to do 3 of them, person B needs to do 3, person c/d each 1 point. When we make our sprint planning, we estimate our story points available to each person in the following weeks, because ppl are not employed on this project only. The task would be assigned to me, showing all the points on my account, while the work for person B is none. This makes it hard ofr us to make correct estimates about our workload. We want to make our esitmations more precise, understand who needs how many points of whom to complete a task. 

We wanted to assign story points to subtasks. I googled and unserstand from the agile manifest, one should only assign points to a task/story. We tried to make "support" tasks and link it to the main task, which is super tredious. We would like to have all the story point planning in one page, to see the progress etc. 

In my old team we estimated points on sub task level, but we used azure devops and not jira. Does anyone has a solution/idea?

[Danut M _StonikByte_]

Hi @Imre Antalfy,

Although the agile by the book does not recommend estimating sub-tasks in story points, you can do this in Jira if you want. 

Make sure that the Jira screen of the sub-tasks displays the Story Points field. Once you do this, you will be able to set Story Points on the sub-tasks.

As far as I can see, now Jira allows setting the sub-tasks estimate directly from the Backlog tab.

But, if you decide to follow this approach, be aware that for keeping your project reports accurate, you will need to consider some additional things:

1. When you set story points on sub-tasks, you will have to subtract the same amount from its parent story in order to not mess-up the overall project estimates. 
2.  The Jira reports (sprint, burndown, velocity) do not consider the sub-tasks estimates, so you reports will not be accurate. Fortunately, you can easily solve this by using our Great Gadgets app.  It offers advanced dashboard gadgets (sprint burndown /burnup, release burndown/burnup, velocity) that allow tracking agile projects and they have the option to include the sub-tasks in the calculation. 

I hope this helps. If you need any help on setting this up, please contact us at support@stonikbyte.com.

Thank you,

Danut Manda

[Imre Antalfy]

heyho, thanks for the input. as always there is an appa s a solution ;-)

[Randy O_Neal]

So... we've wrestled with this issue for as long as we've practiced Agile... be it as a Scrum team or as a Kanban team, though the questions may be slightly different.

We always* estimate stories via story points at the story level; we estimate sub-tasks in hours.  The rationale is we are far more likely to accurately estimate smaller sub-tasks in hours than the entirety of the story.  However, that makes story point estimation a more complex undertaking.  If, for example, you have 8 sub-tasks of equal size and duration, it doesn't necessarily mean the sum of those 8 sub-tasks equals an 8-point story.

Most - not all - Agile coaches will concede that story point estimations ultimately boil down to duration.  For example, this is the general guidance we use regarding story points and duration:

• 1 Point: up to a day
• 2 Points: more than a day, up to 2 days
• 3 Points: more than 2 days, up to 3 days
• 5 Points: More than 3 days, up to a full week
• 8 Points: More than a week, but less than a full sprint (sprints being 2 weeks)
• 13 Points: More than an 8 and up to the entire sprint
• 21 Points: Too large to fit in a single sprint; the issue must be split

So, the question is whether you can run some of your sub-tasks in parallel or not?  If you can, you may find that all 8 of your sub-tasks can be completed in a 3 point or 5 point story... perhaps even less.  However, if they have to be completed sequentially, then it may rather be an 8 or even a 13.  Tracking would be at the sub-task level, and there are several ways you can track your own individual sub-tasks.

HOWEVER... you might be better off splitting that story into smaller stories, which can be individually assigned to each of the responsible developers (which would simplify the reporting issue you are having).  You could even have a small epic with the individual split stories associated so you could track both the epic for completion as well as the child stories individually as well as at the sub-task hour level if needs be.

* When we switched to Kanban, we also walked away from story point estimation; rather than estimate by story points, we meet, discuss the issue, and ask the question "Can this be completed in 3 to 5 days (or less)?"  If the team agrees that it can be, then we consider the story Ready.  The team identifies sub-tasks, but we no longer estimate the sub-task hours either; knowing the work that needs to be done is sufficient.  We then simply put ourselves to the task of "doing the work".

I realize this approach will not work for everyone, but it works very well for us.

[Imre Antalfy]

This is the insight i was looking for, thank you for your time.

We are currently splitting it up in smaller tasks, one for main task for exmaple with 3 points and one support [name of main task] task with maybe 1 point for the review or support in a meeting etc. Our main goal is really to get our estimation to a better point. We are always able to complet 3/4 of a sprint, only once it happened we got one through.

What will you to if the team disagrees with the story ready? does the reporter go back to make a better story? My team often complains it is not possible to plan their work, to specifically define what the want to achieve. but maybe we should go away from tasks and focus more on stories

[Randy O_Neal]

@Imre Antalfy the approach I outlined above (regarding dropping story and task hour estimation entirely) was only possible to achieve with a very mature team; my teams have worked closely together for the past 3-4 years at least... some have been working together for 8-10 years.

During grooming/refinement, we specifically ask the team if they consider the issue Ready; if they say no, we continue discussing the issue; if they say yes, only then do we proceed to mark it Ready.  We never force the issue to be considered Ready.

If your team is complaining it's not possible to plan their work, it sounds like the issues are too large.  I'd respectfully recommend you revisit your issues to ensure:

1. They're focused on the WHATs, not the HOWs.  "Stories" that describe the HOWs are nearly always not well-formed user stories... rather, they are a list of tasks.
2. They've been properly refined to the point the team agrees the issue is well enough understood to be considered ready to groom.  Also, we use a techdiscussion label to identify anything that needs further technical discussion within the team, and we hold a tech discussion immediately following each of our grooming sessions (we have two each week); if there are any DEV-level tech discussion points which need to be hammered out.
3. They're narrowly focused on small deliverables (if there's an AND in the requirements, that's probably a good place to split the story).
   * If the team feels they need to "plan" their work, you should be asking "Why?"  Under Scrum, the team is supposed to plan the sprint prior to establishing a sprint commitment.  This planning session should take no more than 1-2 hours for a 2-week sprint.  Under Kanban, the team is supposed to plan the issue (story or bug) when they prepare to bring the next most important issue into progress.  If they are planning more than that, then you're probably either working with a less-than-mature team, or you're working in a construct other than either Scrum or Kanban.  From my experience, teams which feel they aren't afforded enough planning time are often operating more in an "AgileFall" methodology rather than truly either Scrum or Kanban.

And... yes, if the team disagrees with the story's "readiness", it does fall back to the Product Owner to go back a "make a better story".

Hope this helps...

Randy

[Bill Sheboy]

Hi @Imre Antalfy 

Rather than using story points, has your team discussed using time-based estimation instead?  That may better align with estimation at a sub-task level, could be forecast on "effort to complete" in time, be rolled up by person (or parent issue), and so help see the impact when the amount of work in progress (WIP) is higher.

Perhaps discuss this with your team scrum master / agile coach for ideas.  Based on what you describe, they may also suggest learning about Kanban or Scrumban based approaches rather than Scrum.

Kind regards,
Bill

[Imre Antalfy]

Thanks for the input bill. Im the scrum master, I will have a sincere argument with myself about the topic haha