Update story points for user story according to sub-tasks

How do you typically "score" your stories? You mention you have developers and QA separately so do you just combine the story points, average them out or break them into separate tasks within the story? 

Seems to me this should not be 1 story, instead it should be broken down into 3 different stories. I could be wrong but that is what I would lean towards. 

- DBA needs to do some changes in DB and he wants 2 story points for that. 

- Dev team needs 4 story points for development.

- QA team needs 2 story points for testing. 

Actually on one use story, 3 different peoples will work .

From the behaviors you are seeing now, how likely is it that people will work collaboratively on this story once it is underway?

Vishal, when you say

individual story points burn down calculation

you mean that you want a burndown of the work per team so that you can radiate progress from the three different teams involved in this parent story?

Vishal,

I would question your use of story points.   It does not seem to reflect a collaborative estimate of the size and complexity of the item to be delivered; instead, it is a "sum" of the silo-ed efforts needed.

Instead of asking different members of the Dev Team to provide separate estimates based on their expertise, can the team as a whole assess the size and complexity of the item?   Almost always, people will "rank" items across a 5-scale (i.e. - x-small, small, medium, large, x-large).   A range greater than 5 is too fine, and people will gravitate to using only 5 values.   A range smaller than 5, and there are too few options to choose from.

I would ask the entire Dev Team (everyone capable of contributing to completion of the item) to assess whether the item falls under one of the 5 categories (XS, S, M, L, XL).   You can always equate a number to the size value afterwards (ex: 2-3-5-8-13).

You can always estimate sub-tasks (I'm personally not in favor of that practice), but if you choose to do so, estimate in actual time components and not in relative terms such as story points.   You already have your item "size" - no need to relatively estimate the sub-tasks in the hope that it will somehow "roll up" and equal the parent story point estimate.

How do you typically "score" your stories? You mention you have developers and QA separately so do you just combine the story points, average them out or break them into separate tasks within the story? 

Seems to me this should not be 1 story, instead it should be broken down into 3 different stories. I could be wrong but that is what I would lean towards. 

After thinking this question through again, I realize I wasn't on the same page and don't like my initial reply.

What I should have replied with is:

What benefit would be found by applying story points for each sub-task as opposed to just assigning the story an estimate as a whole? Whether you have 3 tasks (1 for 4 points and 2 for 2 points each) or just a single story point estimate of 8 given to the story; the total is still 8 for complete this backlog item. Assigning story points by tasks looks like extra work with no ROI.

Hi Curtis Slough

What benefit would be found by applying story points for each sub-task as opposed to just assigning the story an estimate as a whole? Whether you have 3 tasks (1 for 4 points and 2 for 2 points each) or just a single story point estimate of 8 given to the story; the total is still 8 for complete this backlog item. Assigning story points by tasks looks like extra work with no ROI.

Answer: 

- As long as productivity is measured as Team's productivity (e.g. Entire Team delivered 50 story points in 2 week's sprint), this approach is fine. i.e. Giving story points at user story level. 

- But when we needs to measure individual productivity, there is issue. e.g. In above scenario, if story points given at user story level, 8 story points will be burn down to whom user story was assigned. Although DBA and QA worked on the sub-tasks as a one team. 

- In our team, for each user story, we crate sub-task for QA. But story points are burnt down on Dev members name as user story is assigned to Dev member. So QA's productivity is not seen in terms of story points. 

So I thought If we give story points at sub-task level, this issue will be resolved. 

It will be great help if you will suggest any other alternative to measure individual productivity in terms of story points burn down. 

Thanks in advance. 

Vishal Pachpute

I just want to clarify one thing from my original post

Actually we have one team including Dev, QA, DBA members. 

And to summarise, issue is about measuring individual productivity in terms of individual story points burnt down instead of entire teams of productivity. 

It's my mistake I written different teams. Sorry for that. 

Vishal

Why do you need "measuring individual productivity"? What value does it add, at what cost? How will measuring individual productivity foster teamwork and helping each other? Will it help stakeholders?

If you have to do it, you can do it in the way you suggested in the original post, and then maybe the tool you use to manage backlogs might help you to keep track of all the points - but is it really needed?

But when we needs to measure individual productivity, there is issue... It will be great help if you will suggest any other alternative to measure individual productivity in terms of story points burn down.  

How about... not?

You would be well-served to study the Scrum Guide further:  

• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Scrum frowns upon any attempt to single out and measure individual productivity.   It is inherently detrimental to team formation and maturity.   Measuring individual productivity is a very visible symptom of mistrust.   

Can you (and your management) get to the point of trusting the team as a whole to complete the work that they forecast?   If not, why?

How about... not?

I seriously laughed out loud at reading this, thanks Tim.

I'm really curious about the question that Filip posed regarding why you need to measure individual metrics.

I may be wrong but in my studying and reading of various Agile frameworks, I have yet to come across one that supports individual metrics. Where did this idea come from for you and/or your company?

I have a question on this. Looks like a very old post but I am having one challenge. In case if I want to see a progress in terms of burn down after closing each sub-tasks present in a story. How it can be achieved? Here idea is not to see the individual team's performance as I understand that in Agile there is a one team (PO, DEV, QA, DBA, DevOps etc etc) but to see how we are progressing on a daily basic.

If we can have story points at sub-tasks level, closing any sub-task - burndown will be updated and as a result we will know the actual progress of any story?

I am not sure if I am missing anything here. thanks!

Backlogs are to burndown. if you think sub-tasks are closed daily or sooner, Why not track you burndown based on number of sub-task items ?

I'm just going to say it. Do you really think you will ever get burndown chart to look like the ideal?  It will never happen. Ok, off my soapbox. 

The Daily Scrum is so that the Developers can discuss progress so far in the Sprint and plan for the current day's activities. That is how progress is monitored and the Developers monitor it themselves. In your scenario, you would have to add new tasks for any new work identified from new information gained. In that case your burndown chart could actually show upward trends. That can give a false sense of incompleteness. I'm also going to point out that you are "burning" estimated values that will usually be invalid once actual work begins. 

In my opinion, using burndown charts to monitor progress is a really bad idea. I prefer to trust the Developers to monitor their own progress and to raise awareness if they feel there's a chance of missing the Sprint Goal. That is the purpose of a Sprint, completing the Sprint Goal. It is not to finish every item in the Sprint Backlog. 

Better to divide user story into 3 individual user stories-

1. DBA

2. DEV

3. QA

This way its better to follow the efforts, tasks. Agree that scrum favours team productivity as a whole. however its fact that first DBA work on task, then Dev, then QA.

This separate user story allows everyone to work on thier respective part in planned manner in single sprint or different subsequent sprints, without wastage of time.

In above mentioned example - if DBA is working on its part of user story, DEV and QA can pick up other stories to work on, rather that waiting or working on incomplete source of truth.

This was efficiency and effectiveness of everyone can be harnessed and team can become self organize gradually.

Hello - You may consider procuring a tool like Jira Software, ensure to have sub-tasks on each team and maybe not StoryPoints but Value Points in terms of how many hours will you work on the task.