story assignment during planning
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.
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.
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.
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).
> 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".
> 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.
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?
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.
+1 to Ian's answers. Thanks for your contributions to this board, Ian!