Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
Guardrails to Decomposing Stories
Network:1780



Interested to hear any thoughts or opinions on a particular strategy, criteria, or threshold around identifying when a story may be too large by the number of associated sub-tasks.

For example, if a story has 12 sub-tasks, is that possibly a red flag the story may be too large and should be looked at for splitting? How about if a story is sized as an 8, but has 14 sub-tasks, with some estimated at 8 or above hours?

Realize that what works for the team is generally the approach taken, but at the same time, you want to coach them to strive toward a certain level of maturity by challenging themselves on continuous improvement and efficiency.
Sort By:
Network:1186



Andrew, I know you are master of this however what I understand is that Sprint backlogs with many small user stories improve the flow in a sprint, enable you to regularly deliver business value to your customer, but you want to decompose so that can be manageable to your team with smoother burndown to maintain sprint with less risk to fail, it has to be self contained increment of value, with larger item it is harder to handle so the number does not really matter if it is all equal and manageable and to calculate that you have three methods which are

1. The CRUD Method ;- Create, Read, Update and Delete operations in stories.

2. Business Rules;- it has a number of explicit or implicit business rules, and this may provide another way to breakdown your stories.

3. Workflow Steps;- user stories often involve a workflow or logical step-by-step process, it can be self-contained increments of value.
...
1 reply by Andrew Craig
Jun 05, 2018 7:15 PM
Andrew Craig
...
Thanks, Riyadh. Agreed. That is my thoughts as well and my rationale for thinking it is merely a maturity issue, that will be resolved naturally through progression, comfortableness, and experience in the new environment.

Regardless, someone should be challenging the team to help guide them through the journey, not being prescriptive, but doing their due diligence as a Scrum Master or Agile Coach.
Network:284



Number of subtasks, duration and experienced WIP Limit of the team provides some indication to further decompose the respective stories following the proposed split strategies from Riyadh..
...
1 reply by Andrew Craig
Jun 05, 2018 7:22 PM
Andrew Craig
...
Thank you, Peter. Hopefully, some concerns or ideas will come out in the retrospectives.
Network:1576



Andrew, there is not a new path to do that. Is the same technique that come from 1960 up to date. You have to use decomposition maintaining low coupling and high cohesion. On the other side the same principles than modular programing or object oriented programing. Few people know that User Stories cames from object orientation and were "invented" for people that created XP. I was the pleasure to work with Allistar Cockburn and Kent Beck at OOSPLA several years. So, my recommendation, is going to XP documentation and mainly Kent Beck website to know about that BUT as I mentioned better is going to previous documentation from Dijkstra, Hore, etc.
...
1 reply by Andrew Craig
Jun 05, 2018 7:23 PM
Andrew Craig
...
Good points, Sergio. Thank you.
Network:803



Andrew -

I'm not a fan of excessive story decomposition into sub-tasks. After all, sub-tasks don't deliver value by themselves, and their only value is to increase shared understanding within the development team as to how a story will be delivered. If one person is going to do the majority of work to complete a story, sub-tasks are really unnecessary, so if they are primarily used to divide work among multiple team members, then I'd feel that anything over 4-5 is overkill and would look to split the story proactively during the lookahead planning which should happen 1-2 sprints before the story is likely to be worked on.

Kiron
...
1 reply by Andrew Craig
Jun 05, 2018 7:26 PM
Andrew Craig
...
Totally agree, Kiron. I make recommendations to some of the teams, though I am not directly involved. I have team members dispersed throughout. We speak internally, I provide my feedback and coaching. Then possibly through team cohesion and retrospectives some of that can be turned into suggestions for improvement.

Some of the basis for my question out to the community was also due to a fear that some of the sub-task creation and hour estimation is to measure individual contributions. Maybe that is natural coming from a command and control environment.

It's certainly a maturing process.
Network:1780



Jun 04, 2018 9:01 PM
Replying to Riyadh Salih
...
Andrew, I know you are master of this however what I understand is that Sprint backlogs with many small user stories improve the flow in a sprint, enable you to regularly deliver business value to your customer, but you want to decompose so that can be manageable to your team with smoother burndown to maintain sprint with less risk to fail, it has to be self contained increment of value, with larger item it is harder to handle so the number does not really matter if it is all equal and manageable and to calculate that you have three methods which are

1. The CRUD Method ;- Create, Read, Update and Delete operations in stories.

2. Business Rules;- it has a number of explicit or implicit business rules, and this may provide another way to breakdown your stories.

3. Workflow Steps;- user stories often involve a workflow or logical step-by-step process, it can be self-contained increments of value.
Thanks, Riyadh. Agreed. That is my thoughts as well and my rationale for thinking it is merely a maturity issue, that will be resolved naturally through progression, comfortableness, and experience in the new environment.

Regardless, someone should be challenging the team to help guide them through the journey, not being prescriptive, but doing their due diligence as a Scrum Master or Agile Coach.
Network:1780



Jun 05, 2018 1:55 AM
Replying to Peter Ambrosy
...
Number of subtasks, duration and experienced WIP Limit of the team provides some indication to further decompose the respective stories following the proposed split strategies from Riyadh..
Thank you, Peter. Hopefully, some concerns or ideas will come out in the retrospectives.
Network:1780



Jun 05, 2018 5:53 AM
Replying to Sergio Luis Conte
...
Andrew, there is not a new path to do that. Is the same technique that come from 1960 up to date. You have to use decomposition maintaining low coupling and high cohesion. On the other side the same principles than modular programing or object oriented programing. Few people know that User Stories cames from object orientation and were "invented" for people that created XP. I was the pleasure to work with Allistar Cockburn and Kent Beck at OOSPLA several years. So, my recommendation, is going to XP documentation and mainly Kent Beck website to know about that BUT as I mentioned better is going to previous documentation from Dijkstra, Hore, etc.
Good points, Sergio. Thank you.
Network:1780



Jun 05, 2018 7:58 AM
Replying to Kiron Bondale
...
Andrew -

I'm not a fan of excessive story decomposition into sub-tasks. After all, sub-tasks don't deliver value by themselves, and their only value is to increase shared understanding within the development team as to how a story will be delivered. If one person is going to do the majority of work to complete a story, sub-tasks are really unnecessary, so if they are primarily used to divide work among multiple team members, then I'd feel that anything over 4-5 is overkill and would look to split the story proactively during the lookahead planning which should happen 1-2 sprints before the story is likely to be worked on.

Kiron
Totally agree, Kiron. I make recommendations to some of the teams, though I am not directly involved. I have team members dispersed throughout. We speak internally, I provide my feedback and coaching. Then possibly through team cohesion and retrospectives some of that can be turned into suggestions for improvement.

Some of the basis for my question out to the community was also due to a fear that some of the sub-task creation and hour estimation is to measure individual contributions. Maybe that is natural coming from a command and control environment.

It's certainly a maturing process.
Network:1186



Andrew , good discussion thanks for putting this question

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so."

- Douglas Adams

ADVERTISEMENT

Sponsors