story assignment during planning

Last post 12:25 pm June 23, 2014
by Charles Bradley
7 replies
Author
Messages
07:28 am June 21, 2014

Hi , Here is my question:

I have seen some scrum teams assigning a story to a person during sprint planning. I feel it is not correct.

because,

Reason 1: lets assume 4 stories are taken to sprint backlog which is having team of 270 hours Capacity

6 person X 9 Days X 5 Hours = 270 Hours or 45 man days

if 4 stories are having estimated size = 48 ma days

We can pull all four but when task break up is done, all the 6 team members should share all the stories.
No one owns a story. Team No1 can work on Task1 of story 1 and Task 10 of Story 3.
I feel this where the knowledge flows freely and team emerges self sufficient and self organized. This is where agility comes.

Please suggest if I'm wrong.

07:45 am June 21, 2014

I guess priority is only for PBI, once they are pulled into Sprint backlogs all are equally prioritized. There should not be any sprint level priority.

08:37 pm June 21, 2014

I am skeptical about sprint level prioritization. This is as good as interfering into development teams work (not advisable for a good scrum practice.

Interference into developers work is acceptable unless there is a REAL priority item that needs to be replaced by an existing item in current sprint, but ultimately that should come from product backlog (post refinement etc).

03:33 pm June 22, 2014

> I am skeptical about sprint level prioritization. This is as good as interfering into
> development teams work (not advisable for a good scrum practice.

This depends upon who is doing the prioritization. A Development Team can choose to prioritize certain items on their own Sprint Backlog if they believe it will help them to achieve the Sprint Goal. However, no other party has the right or responsibility to set these priorities. Any attempt to do so could indeed be tantamount to "interference".

03:40 am June 23, 2014

> I guess priority is only for PBI, once they are pulled into Sprint backlogs all are
> equally prioritized. There should not be any sprint level priority.

The Development Team can establish sprint level priorities if they believe it helps them to achieve the Sprint Goal.

Look at it this way. You know that a Sprint Backlog is never frozen, and that a team can revise it as needed during a sprint in order to meet the Sprint Goal. Replanning doesn't stop and Sprint Backlog items can be added or removed if necessary. By definition, if a Development Team adds or removes items from a Sprint Backlog then they are changing sprint priorities. Deciding which to action first, but without adding or removing any from the backlog, could be a comparatively trivial case of replanning to meet the Goal.

03:50 am June 23, 2014

Thanks Ian, Agree. Developers can have their own prioritization details (internally).

Am I right saying that it should not be exposed on task boards or scrum tools (that makes it visible to PO or Stakeholders ?)
Or can that be made visible as long as priority of Sprint can be nailed down to PBlog?

05:40 am June 23, 2014

As a general rule information should be exposed and radiated across the organization, rather than censored. This provides an opportunity for stakeholders to spot problems and/or offer solutions via the Scrum Master.

If there is a danger of parties interfering with a Development Team's work, on the basis of information the team provides, then that is a impediment which the Scrum Master should rectify.

12:25 pm June 23, 2014

+1 to Ian's answers. Thanks for your contributions to this board, Ian!