Automation for sub-taks Story Points relation with parent User Story

[Federico Varchavsky]

Hello,

I need help to have a basis for developing a script to automate US story points in relation with the sub-task it might contain.

I know Jira does not want to work on this and the only way to have this much needed functionality is by scripting it.

Here's what the script should do in order to complete the unincluded functionality:

Before the script:

1- User Stories will start with a set amount of Story Points assigned to them.

2- Sub-tasks are added to the User Stories.

Script process would start here:

2a- Story Points are added to the Sub-tasks.

2b- The parent task should subtract the amount of Story Points added to the sub-task. Making sure that the original Story Points total remain unchanged.

This is because otherwise we'll have the Story Points doubled due to the sub-tasks and parent tasks adding up their story points.

And if sub-tasks are not estimated with their corresponding Story Points... there would be no chart info until the parent User Story is completed.

Please help me start this script so I can modify it as needed.

Thanks!

[Nic Brough -Adaptavist-]

There's a few things in there to unpack:

Atlassian don't want to do it because:

• It is not "much-needed functionality" - people doing Scrum with sub-tasks properly don't need it.  Sub-tasks are not sprint-items and therefore don't need estimates.
• It breaks your system in several ways
  • It won't handle scope change
  • It, as you recognise, causes inaccurate double counting.  (Your proposal partly fixes it, but it will still cause you reporting problem)
  • It forces you into non-scrum patterns, preventing teams from self-governing and losing flexibility

Adding up the points on sub-tasks absolutely does not work, but your proposal of "add then subtract", while your far superior strategy helps a lot (which is the one I recommend when people want to estimate sub-tasks).

To fix it properly (and this helps with the simple "add them up" strategy too), use two estimate fields.

• Entered-estimate goes on both issues and sub-tasks.
• Sprint-estimate goes only on issues.

You then calculate the sprint-estimate from all the entered-estimates on the issue and sub-tasks.  Then you use the sprint-estimate as the board's estimation system

[Federico Varchavsky]

Hi Nic Brough _Adaptavist_, thanks for the answer.

Everything looks great... but if I can not use a different field as a source for the charts... having sub-tasks estimated in story points is a must.

How would you handle this scenario? (without forcing the team take a long time splitting every US into multiple US should it be possible):

-Each estimated US is a whole that will be started and completed during the Sprint. 

(no Epics or US larger than the Sprint)

-Sprint has 10 US, each one has 10 sub-tasks.

-Each sub-task is being worked on every day... everything's moving forward perfectly through the whole Sprint... tasks... sub-tasks... everything being started and getting to Done on the same day.

-Each US, has one sub-task (that's about 0.0005% of the total work of the US) and such sub-task can only be finished on the last day of the Sprint.

I'd appreciate any solution to this that includes having progress information available during the Sprint.

Thanks!

[Nic Brough -Adaptavist-]

You do not have any choice but to use two fields.  If you don't use two fields, you will be double-counting somewhere.

>How would you handle this scenario? 

> Each estimated US is a whole that will be started and completed during the Sprint. 

Yes, exactly how US should be sized

> (no Epics or US larger than the Sprint)

No, that's utterly wrong.  The whole point of an Epic is to represent a large body of work, made up of many many stories.  They don't go into a sprint, they span many sprints and projects.

User stories should always be sized to fit within a sprint - even on the rare times a  story is sized to take up the whole sprint, they must be achievable within one sprint.  That's a rare case though, in most cases, a sprint will contain several or many stories 

>Sprint has 10 US, each one has 10 sub-tasks.

Yep.

>Each sub-task is being worked on every day... everything's moving forward perfectly through the whole Sprint... tasks... sub-tasks... everything being started and getting to Done on the same day.

That entirely depends on how you work.  It's not "wrong" if it works for you.  But it doesn't really matter when you're doing Scrum.  People pick up a story, break it up into sub-tasks if it's the right thing to do, then work on the sub-tasks (and story if there are parts of it not broken out into sub-tasks). 

You don't look at the sub-tasks to judge progress, the question is simply "is the story done or not"?

>Each US, has one sub-task (that's about 0.0005% of the total work of the US) and such sub-task can only be finished on the last day of the Sprint.

Again, that's a process thing. 

The normal model is that a sub-task is marked done when it is done, the developers don't care when it's done, just that it is (or isn't).  The sprint, and reporting, don't care about the sub-tasks. 

There's then a split at the next level up - some people will say "story is done when the last sub-task moves to done" and others will say "story is done when I move it to done" (which I won't do unless all its sub-tasks are done)

Jira Software is built to support both of those, but it'll support your "finish on last day" process fine too.  You're not really doing Scrum if you do that, and Jira is a Scrum tool, but this isn't something it won't support.

[Federico Varchavsky]

Hi Nic Brough _Adaptavist_,

Thanks again for your response.

Here's what I mean about how would you handle it:

Each and every US in the Sprint contains 1 sub-tasks that will only be Done on the last day of the Sprint.

Since:

-All sub-tasks need to be Done for the US to be Done... each US in the Sprint will only be Done on the last day of the Sprint. (when the last sub-task is Done)

and

-Charts will only show me progress on the last day when all US are Done.

How might we do Scrum with Jira if we can not have each US being Done in 1 day?

Should we not use Charts at all?

Should the team take a lot longer to split a 1 Sprint long US to multiple 1 day long US?

(this would not benefit anyone at all... as a matter of fact it'll just add unnecessary and unuseful workload for the team)

Do you all have US that can be Done in 1 day? Really?

[Mark Segall]

Hi @Federico Varchavsky - I would recommend to simply use a custom point field on the story so that can serve as your baseline estimate and then the roll up would simply be your actual.

I'd be remiss if I didn't express why Jira is designed this way. I understand this likely won't change your approach, but I wouldn't expect Atlassian to ever change the way they manage story pointing because they're called STORY points for a reason... At the core of Agile best practices is that everything centers around the story.  Sub-Tasks are generally designed as a way to provide a detailed breakdown of the work that will go into the story (covering the Definition of Done).  When I hear about teams wanting to point individual sub-tasks, it's because they feel that story points should be equated to time and/or individuals.  If you're wanting to track against effort, I recommend leveraging work logs instead.