How do I plan a sprint, given that sub-tasks aren't visible in the backlog?

Question

Ok so I've read a bunch on this forum about how "sub-tasks are useless in a backlog". I can accept how a product owner doesn't care about the subtasks when forecasting and planning long term.

I'm a "scrum master" and I'm assigning sub-tasks out to developers. Myself and the developers need a view to see all the sub-tasks assigned to them in a sprint that has not started yet so they can see how the hourly estimates are adding up. Based on that I'll have to punt items out of the sprint.

We are following the scrum process we were trained by Ken Rubin, the former Scrum Alliance director, so it seems like this would be an expected use-case of a scrum management tool.

Thomas Deiler_db00h3 · Answer

Dear @Roarke Randall .

Sprint backlog shows breaking down stories into subtasks that are estimated in hours.

Of cause the team can estimate sub-tasks in hours. But is it worth to invest time for in depth estimation? Bringing the currency "hours" inside will make the team harder to think in a relative currency. Because they will sum up hours and then have an exchange rate between Story Points and Hours. There is also the psychological effect of hour-estimates. If a team mate exceeds an estimation, he/she feels uncomfortable. With story points is more "inaccurate" and therefore less stressful. Of cause new teams will fail often in the beginning - but Ken will have told you.

Then you start your sprint, break it out into tasks, and the UI person may be overwhelmed, while the backend developers might not have enough work.

By time and practice, the team will evolve. Situations like this will appear less often. But I agree to splitt stories into subtasks before the sprint is started is a reasonable action. But do not estimate them. Estimate the story again after they splitted up and have gained insights.

Me assigning them those tickets is more just a matter of who's performing the action in jira.

For a limited time a scrum master can do, if it is communicated eg. "done by the SM until end of 3rd sprint". As a scrum master do not perform actions the team could do. concentrate in you role as the process owner.

the thread you posted has many customers being told they are wrong in a fairly aggressive tone. That thread also links to a feature request with a lot of support that is being ignored.

Atlassian has it's own rules of implementing features from the community. I do not like to comment this. Atlassian Staff people can do better. I can just say, that the current implementation in Jira Software is close to how Scrum should work. Of cause not perfect. For example the feature that you can have concurrent sprints in one agile board. Therefore I disagree.

And finally a general note on implementing agile methods in a company:

Having trainings and certifications is good. But having an experienced agile coach that assist one team during the journey to agile haven is even better. No trainer that gives any kind of (one-shot) courses has got a deeper understanding of a how the company/team thinks and performs instead of a person that feels the daily heard-beat. Coaching is always individual. It's nothing you can copy to other teams.

So long

Thomas

Roarke Randall · Answer

We are pointing our stories, and time estimating our sub-tasks. The thinking behind this is that pointing is used for velocity & time estimates are used for filling a sprint with tasks. In our scrum training Ken told us to use the time estimates to fill a developers. His flow has the following "stages": Grooming, Sprint Planning, Sprint backlog, and Sprint Execution. Sprint backlog shows breaking down stories into subtasks that are estimated in hours. It's unclear when Sprint Backlog occurs (before or after clicking "start sprint" in jira?), so I may have misunderstood him.

Regarding making sub-tasks during the sprint: (this is an hypothetical example) If you bring in 2 stories to a sprint that both have significant UI work & little backend work, that information wouldn't necessarily be apparent at the planning stage. Then you start your sprint, break it out into tasks, and the UI person may be overwhelmed, while the backend developers might not have enough work. What happens at this point? It seems like breaking the stories down into sub-tasks during the planning stage can help prevent this. Open to ideas though.

Regarding push vs pull, I think that's a matter of semantics as well as a lot of company/team specific process. One of our goals right now from our retro's as a team is to "de-silo", so myself and the developers have had discussions about where they want to gain knowledge. Me assigning them those tickets is more just a matter of who's performing the action in jira.

Another thing I'd like to note is that the thread you posted has many customers being told they are wrong in a fairly aggressive tone. That thread also links to a feature request with a lot of support that is being ignored. I'm surprised Atlassian is ok with that.

Thomas Deiler_db00h3 · Answer

Dear @Roarke Randall ,

You know, if you are a Scrum Master and assign tasks to developers, you breach the concept of Scrum? Let the developers "pull" instead of "push". Pushing things (that's what manages do) does not support the self-organisation of a team.

I can hardly believe, that Kenneth S. Rubin, a man who wrote a bestseller about Scrum, taught you this.

About the sub tasks and the missing view for developers:

Estimation in agile manner is in most cases not done in hours but in story points (see chapter 7 of Kens book). Ideally the team (when experienced) creates sub tasks after the sprint start, when the estimation was already done. Because they already know that the will finish an amount of X stories within the next sprint, that has a fixed time box. New teams probably create sub tasks before the sprint start to better understand complexity or share knowledge. The gained information will help them to estimate in story points.

A separate view of all sub-tasks makes therefore no sense.

Please read the article from Nic for another perspective on this topic.

So long

Thomas