All Subtasks Estimation for a Story in Sprint Planning is it essential? or only planning sub tasks which are in scope of sprint

Last post 12:33 pm August 11, 2020
by Piotr Górajek
13 replies
Author
Messages
11:01 am August 7, 2020

Hi Everyone,

I have stories in my backlog prioritized for sprint planning

For clear understanding of what work gets done by whom, we have broken work of story down to sub tasks(one sub task per person)

Now within a story of a sprint, Lets say I clearly know out of 2 sub-tasks, completing only 1 is possible

Example: Story with 2 subtasks one for dev+one for qa and  only dev is possible to be completed within sprint

Should i plan and estimate both sub tasks of the story or only the ones I clearly know is possible in scope of sprint?

 

04:30 pm August 7, 2020

I have stories in my backlog prioritized for sprint planning

For clear understanding of what work gets done by whom, we have broken work of story down to sub tasks(one sub task per person)

Why? How do you then accommodate emergence, and handle the uncertainty that is inherent to a complex product? How does your team collaborate in the face of change with a shared accountability for outcomes?

05:09 pm August 7, 2020

accountability is shared irrespective of individual task outcomes

this method helps track who is working on what and individual assignment of work between different roles get much clarity and transparency

In cases of scope change or added work...either new stories get added with their respective tasks

or

In case of scope change for that individual sub-task of a story we manage it by changing "remaining time" field(more hrs added or removed based on scope change)

however i am still seeking clarity as to whether all sub tasks be estimated for story at start of sprint or estimate only those sub tasks which we know are achievable during sprint planning

06:32 pm August 7, 2020

however i am still seeking clarity as to whether all sub tasks be estimated for story at start of sprint or estimate only those sub tasks which we know are achievable during sprint planning

Why would the team plan to do work which they do not believe is achievable? If any of their planned work lacks an estimate, how can the team forecast how much of it remains?

09:14 am August 9, 2020

Now within a story of a sprint, Lets say I clearly know out of 2 sub-tasks, completing only 1 is possible

Example: Story with 2 subtasks one for dev+one for qa and  only dev is possible to be completed within sprint

Your approach to splitting is wrong.

You should have people working together to finish the story, not sequentially.

If the team can't finish the story in a sprint, the story is too big and you need to split it.

If the fact you are working on stories "sequentially" rather than "by swarming" means you have stories you can't complete within one sprint, you need to fix that. How can your development team drop their titles and work together to get each task done, more quickly, to the standard needed?

One task that includes "it's been coded and tested" is better than "build it" and "test it" as two different tasks.

10:03 am August 9, 2020

I agree with much of what Garrie Irons has said, but I have something to add on this:

You should have people working together to finish the story, not sequentially.

Indeed swarming is often preferable to having stages and hand-offs; but having specialists in a Development Team is allowed in Scrum, as long as they are able to produce a releasable "Done" Increment within a Sprint.

Having an explicit Kanban workflow that properly acknowledges these stages can reveal bottlenecks, and may provide evidence to later encourage swarming, more cross-skilling, or entirely new approaches to problems (e.g. Test Driven Development).

In terms of splitting, I find examples help to make the point. Imagine your team are asked to design and build a safe, working mountain bike, but they're not going to be able to test it, would you really be in a position to ask people to use it by the end of the sprint? It seems an incredibly irresponsible thing to do.

Instead, rather than splitting out the testing part of this request, how about splitting out some scope? If the team can't produce the mountain bike, maybe they can design, build and test a simple fixed-speed bike, which would allow real customers to safely start using it much sooner.
By doing this, you would already be able to start gaining feedback that is relevant to the ongoing development of the mountain bike. Such as "I find the saddle too difficult to adjust", "I don't like the colour", or "Wouldn't it be great if the bike came with magnetic dynamo lights?"

05:28 am August 10, 2020

But there are 2 sets of people in the team qa and dev
each has a prescribed function

So is it that you are suggesting i need to split my feature in 2 part stories(for scenarios where dev would take whole sprint) 
I need to have one dev story in first sprint whose goal is only to complete dev
I need to have another qa story in second sprint to take over and do complete qa

Is this the approach you guys are suggesting?

10:20 am August 10, 2020

Would this approach allow you to have a potentially releasable increment, if things are not tested?

 

What does the Definition of Done say? Is QA included in the DoD? Actually it should be and then you have one backlog item where Developer develops and after that you have your reviews and potential rework.

01:36 pm August 10, 2020

QA is included in DOD

but what to do if genuinely the dev work cant be broken down further so as to have an increment in the sprint and dev needs complete sprint ?

How to work on such stories... do i need to create 2 stories one for dev and next for qa such that both falls in same epic and that epic gets delivered

OR

Have one story with 2 sub tasks(1dev+1qa) and to estimate only those subtasks which we know are possible in the scope of the sprint

Which approach should be used?

 

02:11 pm August 10, 2020

Goal is to reach DONE for the backlog item within one sprint. If you take out QA, which is part of the DoD, the item is not done.

But I get your point, what if this item takes the developer the whole sprint. Well in that case, check with the team if it is well formulated and follows INVEST. Maybe it can be broken down into two separate stories. Or check if two members of the Dev Team can work on this to get it done faster, so that QA can be done within the sprint.

As for creating two items, one for Dev, one for QA, please consider the I in INVEST. Will those be independent?

02:45 pm August 10, 2020

You might also think about other ways to break the story down.  For example, if this is to build a feature that allow users to enter, update, delete, view items in a general ledger you could break it down so that you deliver the ability to view items, then enter, then update, then delete with each activity being a different story.  In that case you might be able to deliver 2 of the 4 activities in a single sprint and the other 2 activities in the next.   The increment would still be potentially releasable with just 2 of the 4 activities.  This is very much the same idea that @Simon Mayer was suggesting.  

Too often developers will say that you can't break it down any further but there are usually ways.  The key is that the increment needs to be POTENTIALLY releasable.  Each Sprint builds upon the previous increment until time that the Product Owner decides to actually release.  In my scenario, it take 2 Sprints just as it would if you split the development and testing across Sprints. But in my scenario, the feedback loop to the Developer from the Tester is faster and would not result in as much context switching. Think of this.  If you had Developers build something in Sprint A and the Testers validated that work in Sprint B, what would the Developers be doing in Sprint B?   They would be working on something else,  But if the Testers find issues in Sprint B, would those issues be deferred to Sprint C for resolution or would the Developers have to fix them in Sprint B?   Welcome to waterfall.

 

03:01 pm August 10, 2020

But there are 2 sets of people in the team qa and dev
each has a prescribed function

Like I said, having specialists is allowed. But consider, if that's the reason the team aren't able to produce a "Done" releasable increment of sufficient value by the end of a single sprint, perhaps it's an unhelpful approach, and it could be the main problem you need to solve.

Are your Development Team willing to cross-skill, or find better ways to collaborate? How can you help them understand the benefit of this? What help do they need to put this into practice? Do the various specialists in the Development Team respect each other as peers?

Perhaps by investigating those areas, you will uncover the best way to help the team improve; or be in a position to appoint a team that is capable of producing a "Done" releasable increment of sufficient value.

06:32 am August 11, 2020

Like I said, having specialists is allowed. But consider, if that's the reason the team aren't able to produce a "Done" releasable increment of sufficient value by the end of a single sprint, perhaps it's an unhelpful approach, and it could be the main problem you need to solve.

Specialisation is great. 

But every specialist should be able to contribute early, mid, and late, on any user story. They may have to go from being the leader to the supporter - perhaps the dev task has 35 tests to be executed then certainly the dev should do a lot of test planning of those but rather than "pushing more work into test", the dev should pick up some of the test workload so the flow of completed user stories is smoother.

Perhaps a WIP limit at a user story rather than a task level will help ensure the whole team is helping get all of the work done. Wherever the hold up is - that's likely to be where you need to swarm the most and get the "choke point owner" to become better at breaking tasks into ones that need a specialist vs a generalist.

If the user story can't be "done" in a sprint, regardless of reason - you need the user story to become thinner - and I like Daniel's approach - a view only user story has a lot less test effort than a "whole CRUD" user story. 4 sprints right there...each with a relatively reduced QA effort even if the dev thinks "this is stupid". 

 

Just make sure the dev sees there are other things for them to do (execute test cases, do a better job of refining user stories, go interview some users,...) so they don't feel underappreciated.

 

12:33 pm August 11, 2020

How about stop bother if everyone is busy enough, and just start Sprint Planning with the Sprint Goal in mind and simply find answers at two questions along the way together:

  • What we should do to achieve this goal?
  • Do we believe that what we have selected is achievable within the Sprint timebox?

IMHO Focusing on "resources utilization" goes against the empirical approach in complex product development, and more widely against Agility.

Above does not mean that your approach to splitting or estimation is wrong, only you and your team can assess if it is good practice to perform within your context. Nevertheless, if you do not know why do you run a sprint, what you are trying to achieve, and in what direction the whole team is striving for, then you can try anything and get mediocre results at best.
 

When you plan too much work, that more likely is unrelated, then you will lose your focus by too many distractions, work in progress and "fighting priorities", on the other hand, if you plan too vague and too less work you increase risk of Parkinson's law occurrence and undermining everyone commitment by that.