Skip to main content

Priority within sprint

Last post 11:39 pm June 23, 2014 by VS Chandra Mouli Silaboyina
5 replies
02:14 am June 21, 2014

Hi All,

Here is a situation that I am facing in a scrum team. I m a new member of scrum team. The practices are totally confusing.


During sprint planning they are assigning person who is going to work on based on his or her available capacity.
And forcing the person to provide task break up and hours to the task item. he is the sole responsible person to finish the task.

And team will get suggestions to prioritize the sprint backlogs what to do first what next from scrum master.


What I feel is there should not be any priority with in sprint backlogs. all are equally important, they should be delivered by the end of sprint based on the Sprint goal & DoD as shippable features.

Task break up should happen but who works on that should be decided by the team as whole, its their own business and there should not be any external influence on that.

Any person can work on any task based on his skill, Then only the knowledge will flow freely among the team.

Please share your ideas.

Thanks




07:18 am June 22, 2014


During sprint planning they are assigning person who is going to work on based on his or her available capacity. And forcing the person to provide task break up and hours to the task item. he is the sole responsible person to finish the task.


Why not get the entire team involved in this process? I would advise the team to apply bottom-up intelligence and utilize the knowledge of the team instead of constraining the team with the knowledge of 1 person.
Furthermore, it's a bad practise to make 1 person sole responsible to finish a story. If person A is sole responsible for an item, why would I care then? making 1 person sole responsible destroys your team to become self-organized.



What I feel is there should not be any priority with in sprint backlogs. all are equally important, they should be delivered by the end of sprint based on the Sprint goal & DoD as shippable features.


Ideally what the team has initial commit they should strive to finish it. So with that mindset yes priority within a sprint backlog shouldn't exist because at the end of the sprint ALL needs to be done. But what if (and this will happen) 1 story is bigger than what the team has initially forecast? What if the team forecast to finish 10 stories and eventually finished 5?
If I was the Product Owner I would be upset and even MORE upset it these 5 items were the 5 from the lower half... The idea is to always work on items which has the highest business value for the PO so within a sprint backlog there will always be a priority present.








03:28 pm June 22, 2014

> During sprint planning they are assigning person who is going to work on based
> on his or her available capacity. And forcing the person to provide task break up
> and hours to the task item. he is the sole responsible person to finish the task.

Who are "they", these people who are doing this "forcing"? Is it the Development Team themselves? Coercion of a team member is not the same as self-organization. Are there interpersonal team issues here?

> What I feel is there should not be any priority with in sprint backlogs. all are
> equally important, they should be delivered by the end of sprint based on the
> Sprint goal & DoD as shippable features.

It's the Sprint Goal that's important, so you could turn this around. All items in a Sprint Backlog are all equally *unimportant*.

The Development Team wholly own their Sprint Backlog. As such, it is up to them to decide which (if any) priorities should apply to Sprint Backlog items. These priorities could - but might not necessarily - relate to the delivery of business value. This is because in Scrum the Product Owner can expect to receive an increment by the end of the Sprint, but has no right to expect intermediate deliverables. In other words the PO has no right to set Sprint Backlog priorities in order to receive a deliverable part way through a Sprint. It is arguably possible for the PO to *negotiate* such an arrangement with the team, but they are under no obligation to support a request of this nature.

Sprint Backlog priorities can also be technical. For example, suppose we have the Sprint Goal of allowing registered users to log in to a site. The Development Team might reasonably decide to action any "registration" user stories before those for logging in. Those Sprint Backlog items are therefore prioritized. That could be perfectly reasonable behavior on the part of a self-organizing team.


04:29 pm June 22, 2014

Did you get any explanation why the team forces its members to get particular task?

Each member should decide what to do. It's called pull mechanism and it's important part of Scrum. What you describe is push in fact.


12:24 pm June 23, 2014

+1 to all of the above. Sounds like to me a team who thinks they are doing Scrum but is not even close. Probably could use some Scrum training or refresher training.


11:39 pm June 23, 2014

I do agree to all your opinions. Thanks a lot. The reason why the team is practicing a process which sounds like scrum but not is SM is not trained, still living in the people management era. Managing people not process.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.