Skip to main content

Priority in sprint

Last post 12:01 pm March 3, 2016 by Timothy Baffa
9 replies
Anonymous
09:42 am March 2, 2016

It's obvious that the Product Backlog is prioritise my value.

Based on this prioritization, the team adds the items in their sprint.

During the sprint, is it important to work from top down? or doesn't it really matter anymore as the sprint backlog is owned my the team and they self organized they're way to finish the items in the sprint

greets, Ross


10:07 am March 2, 2016

> During the sprint, is it important to work from top down? or doesn't
> it really matter anymore as the sprint backlog is owned my the team
> and they self organized they're way to finish the items in the sprint

It's up to the Development Team how they order the Sprint Backlog. They own it. The Sprint Backlog is their plan and forecast of work for delivering an increment that meets the agreed Sprint Goal.

However, if the team have agreed to deliver a number of small increments during the Sprint, in order to meet a Goal in which value is delivered as early and often as possible, then the order may be important to other stakeholders such as the Product Owner.


Anonymous
10:35 am March 2, 2016


Posted By Ian Mitchell on 02 Mar 2016 10:07 AM
> During the sprint, is it important to work from top down? or doesn't
> it really matter anymore as the sprint backlog is owned my the team
> and they self organized they're way to finish the items in the sprint

It's up to the Development Team how they order the Sprint Backlog. They own it. The Sprint Backlog is their plan and forecast of work for delivering an increment that meets the agreed Sprint Goal.

However, if the team have agreed to deliver a number of small increments during the Sprint, in order to meet a Goal in which value is delivered as early and often as possible, then the order may be important to other stakeholders such as the Product Owner.



So if it is up to the team, there is a chance that what the PO wants first want be delivered first?


11:43 am March 2, 2016

> So if it is up to the team, there is a chance that
> what the PO wants first want be delivered first?

If the PO specifically wants something delivered before the end of the Sprint, he or she must agree that with the Development Team.

Scrum has nothing to say about the ongoing delivery of releasable work before the end of the Sprint. However it does not forbid this means of delivery. In short, it's up to the Development Team and the PO to agree how and when the increment ought to be delivered. The guiding principle is that value should be maximized.


Anonymous
02:25 pm March 2, 2016


Posted By Ian Mitchell on 02 Mar 2016 11:43 AM
> So if it is up to the team, there is a chance that
> what the PO wants first want be delivered first?

If the PO specifically wants something delivered before the end of the Sprint, he or she must agree that with the Development Team.

Scrum has nothing to say about the ongoing delivery of releasable work before the end of the Sprint. However it does not forbid this means of delivery. In short, it's up to the Development Team and the PO to agree how and when the increment ought to be delivered. The guiding principle is that value should be maximized.



Not perse wanting someething to deliver before the end of the sprint but more the sequence.
For example in a sprint there are only 2 items.

The priority defined by the PO is:

1. Story A
2. Story B

During the Sprint the team decided to work on Story B first as they are owner of the Sprint Backlog. Now the sprint ends and the Development team has only delivered Story B while Story A had more value for the PO.

If the Dev team is in charge of which items will be addressed first, the above scenario can occur right?


02:53 pm March 2, 2016

Yes, it can occur.
If the Sprint Backlog contains only 2 items, there is a big chance that only 1 of them will be done by the end of the Sprint.
The PO accept that risk at the beginning of the Sprint.

It is the reason why Dev Team usually craft a Sprint Baklog with a handfull of PBI and not only 2.

If the goal of the PO is to have Story A, why adding Story B ?


03:56 pm March 2, 2016

One of the attributes of a Product Backlog Item is its value. Development Team members can take this into account when planning and ordering the forecast of work on their Sprint Backlog.


05:37 pm March 2, 2016

It seems to me that the team should try to preserve as much as possible the priority order provided by the Product Owner. The goal must be around providing the greatest amount of value to the business.

For example, say there are 10 stories offered by a PO that together make up a sprint goal, and the team accepts the offer. To me, in the event that the team is unable to complete all of the work accepted, the likelihood of achieving the sprint goal is much higher if stories #9 and #10 are de-scoped, as opposed to stories #1 and #2.

My suggestion to the team would be to preserve the priority order of the offer (which has already been discussed with the PO during Sprint Planning). Stories should be selected and worked on starting from the top on down.

Team renegotiation of the sprint backlog order seems to be a wasteful activity to me. I also believe it is quite risky to ignore the most critical story (or stories) in the sprint backlog in favor of other stories lower in the list.


Anonymous
02:26 am March 3, 2016


For example, say there are 10 stories offered by a PO that together make up a sprint goal, and the team accepts the offer. To me, in the event that the team is unable to complete all of the work accepted, the likelihood of achieving the sprint goal is much higher if stories #9 and #10 are de-scoped, as opposed to stories #1 and #2.


Your goal should encapsulate all stories.



My suggestion to the team would be to preserve the priority order of the offer (which has already been discussed with the PO during Sprint Planning). Stories should be selected and worked on starting from the top on down.


That's the question.... The PO is owner of the Product Backlog but the Dev team owns the Sprint Backlog. So in theory the PO can say this is my preference sequence a, b, c, d. So a, b, c, d goes into the sprint but the team decides its more effecient to finish b,d


12:01 pm March 3, 2016

We all know that this discussion is moot if the development team is able to complete all of the stories that they accept into a sprint. We know however that this isn't always the case.

So while a,b,c, and d make up a sprint goal, where are the "nice to have" stories in the sprint offer? More than likely, they are at the bottom of the offer, even though all stories offered make up the sprint goal.

Can the development team achieve the sprint goal without completing all of the stories? It is certainly possible. It is far more likely though that the sprint goal would be achieved through completing the more critical stories as opposed to the "nice to have" stories. That is why I would strongly suggest working from the top down as much as possible, so that in the event the sprint needs to be de-scoped (while still achieving the sprint goal), the lower-priority stories (less critical), that have not started yet can be removed.


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.