Priority in sprint
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
> 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.
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?
> 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.
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?
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 ?
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.
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.
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
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.