Why pulling x amount of PBI into the Sprint based on Velocity?

Hi Pablo,

There a few thoughts that come to my mind, but perhaps I can have those reading this thread consider the following --

Why use velocity at all?
http://kenschwaber.wordpress.com/2012/05/25/waste-not/
.
.
.

I do agree that the work the Dev Team takes on should be understood by all.

Could you elaborate whether your question was directed toward Sprint Planning or something mid Sprint? Or....?

Hi Pablo

The disadvantages to this way of working include:

- No clear sprint goal to aim for, which means
- No clear value to an end-of-sprint incremental release, resulting in
- A reduced ability to de-risk uncertain project scope, and
- A reduced ability for external stakeholders to plan

Sometimes these things aren't important (e.g. in support or "business as usual" work). In these cases other agile methods such as Lean-Kanban can be used instead of Scrum. In Lean-Kanban you typically don't have sprints or sprint backlogs. You just have a single backlog that is actioned by priority and quality of service, and regular heartbeats to gather metrics and to provide inspect/adapt opportunities.

I 100% agree with Ian, if you don't have a clear goal your team will end up in chaos.

1) The team defines a goal during the Sprint Planning Meeting part 1.
2) Based on the goal the Scrum team selects the User Stories (MMF) that is needed to meet the Sprint Goal. Note here that the MMF needs to be fine-grained and extra Stories can be added once we learn more about the software.
3) The Development team than does the estimation during the Sprint Planning Meeting part 2 for all the User Stories to meet the Sprint Goal. To keep it manageable our Sprint Goal is also potential releasable.
4) When the estimations are done, the team selects all the estimated User Stories in the Sprint.
a. At the end of a Sprint we simple see how much has been done, set up an initial planning based on the velocity and include ALL the remaining User Stories that wasn’t finished within that iteration.

In the end, the velocity of a team can fluctuate which makes the estimations purely a guideline. How often does it happen that a team adds/ removed User Stories during the Sprint due to external factors?

This way we just add all the Stories and start working on them…

Perhaps a bit against the unconventional, but I would say if it works for your team as in they aren’t complaining or gets demotivated about the fact that they never “complete a “successful Sprint, why not?

As long as the Scrum team shares a common goal, takes ownership of meeting that goal, and the PO is happy with the predictability of the team I don’t see the problem…

Perhaps I’m just being a bit too pragmatic ;-)

Perhaps a bit unconventional*

Sorry typo...

Pablo

> Why not just pull in all the PBI’s that are fine-grained (according to a Definition of Ready if the team has one) and see how much can be done within a Sprint?

Let's say a team has 20 stories that are fine grained and they estimate will take around 5 sprints to accomplish. Are you suggesting that they pull all 20 in and just start working them in any random order? If not, what exactly are you suggesting?

Maybe a concrete example would help here.

Exactly, take in all the Stories but do work in priority that is defined by the Product Owner.
Never have to worry about not having enough stories in the sprint and you keep the ambition level of the team high.

But I think a better approach would be to first define goals and then achieve them. Not just take all PBIs and then "complete only as much as you can"

http://www.agiledistributed.com/

Let's say if the team did define a goal and they start a Sprint.
Now 3 things can happen:

1. They finish all the items that meets the Sprint Goal. In my experience the chances that a team finish exactly has what is forecast is small. Not impossible, but smaller then over or under commit. (forecast) Why? Because estimation is hard and the chances that you are wrong is much higher than that you are right. So a team should always take velocity as a guideline rather following it blindly.

2. The team finish too early. This would implicitly mean that they meet their goal so extra items are added. So what's the Goal now? Original Goal + 1?

3. The team doesn't complete all the items. So the Sprint Goal isn't achieved. So new goal will be set up and new Sprint will start.

So what's wrong with pulling all the items in and just work on them. If a goal is really considered important, fine look at your highest prio item and set up a goal with the team while the other Stories are also on the bord but NOT included in the Sprint.

For me a sprint goal doas not mean "finish PBI-Item 2013, 2014, 2015 and 2016". A goal should show the team a line on which they can decide what they want to do and what to do if something unexpected occurs.

So it is not always the case that a sprint goal is not achieved when you do not finish all the PBI's. If this is what you want, then it has a taste of micromanagement for me.

And I think the thought of keeping your teams ambition level hight with this can end up at some kind of student syndrome

Hi Philipp,

I agree with you on the idea of having a Sprint Goal. If you read carefully I was explaining a couple of scenario IF they want to define a Sprint Goal.

A Sprint Goal is always define with the intention that it can change. A goal is nice and it keeps the team focus but it's never strict. It can change during the Sprint once you learn more about the software etc.

So long story short, why not just add all the important fine-grained stories, work on the stories with the highest prio, measure your teams velocity.
It's in my opinion the same as other expect that your Sprint Backlog is always full.

I don't think that the goal is something that is defined with the intention to change. I think that everything else can change but not the goal and if the goal changes then this is the time where you abort the sprint.

You learn more about the software and this will help you to find different ways to achieve your goal by working on other stories or using other technical ways then used before, but the goal is what you want to achieve, and I wont change it during a sprint.

But that is just what I hope to find in a goal or what I want to give my team as goal.

Hi, Pablo,

What you are proposing sounds more like Scrumban than Scrum. It may work for mature products which are in the sustenance phase, but I have my doubts about those early in their life cycle.

One disadvantage I see is that it does not encourage the team to put a serious effort in estimation and improving its accuracy. Agreed, when push comes to shove, you sacrifice scope in favour of schedule and quality. But that doesn't mean you should purposefully plan for an ambiguous scope. It's only when push comes to shove you have to make that sacrifice.

In other words, I find it unacceptable that the dev team tells the PO, "Hey, we're doing our best. At the end of the Sprint, we'll have Done what our velocity permits. We know your priorities, now go away!"

No. I'd rather tell the PO, "We are taking up these N PBIs this sprint, and have a 90% probability that we'll be Done with all of them." More importantly, I want that 90% to slowly inch up every iteration, to as close to 100% as possible. The only way the inching up can happen is if the team picks those N PBIs, fails, then retrospects why, and does better next time.

On the other hand, if your PO is OK with what you propose (which I find unlikely), then by all means ...

Vasan