Overfilling sprint but not overcomitting

Last post 06:31 pm May 26, 2016
by Paud Macken
19 replies
Author
Messages
07:08 am May 24, 2016

Hi folks,

Can i pick your brains on something? :-)

My team is very technically talented but quiet and new to scrum. We do have a Scrum Master but he is also learning the role and has other jobs on his plate.

Out of 3 developers, 1 will be missing for 50% of the sprint and another will experience drag (off sprint) of approx 25%.

We had planning straight after refinement yesterday for sprint 1 of our latest release. We "committed" (I use this term loosely, you'll see why very soon) to 46 points. This figure is typically a full sprint commitment. Our team isn't mature enough yet to have an established approx figure of velocity.

I questioned this figure this morning to the team via our chat application. The one reply I got was from the PO.

"If we don’t make it we don’t make it. The stories are small enough so that we can focus on closing each one off. It’s not the end of the world if we don’t get through the whole lot"

Now this reply confuses me. What is the point of planning if we have this approach or mindset? We don't break down stories in to tasks in planning either. We compile a sprint where the total story points equal way over what we can achieve! Finally, we don't really care what the total is as "if we don't get through the whole lot" it is "not the end of the world".

So I have a few questions:
(1) Is this approach of overfilling but not over-comitting acceptable? In my head I'm thinking it is and I can't imagine what that message says to inexperienced staff or people with very little experience with Agile
(2) Should we be breaking down the stories in planning? We did a survey recently and some staff members thinks there is no problem estimating in planning and just having the one global meeting. I know all this sounds like we need Agile training but the company has twice gotten an Agile expert in to chat to us. Some people just don't see the benefit and want to come in and do their bit and do what they're told.
(3) Given that PO was the only one that replied, should this question be going out to the scrum team (dev, QA, scrum master etc) and is it their decision?

Thanks!

07:49 am May 24, 2016

Hi Paud,

Please can you clear your role in the team?
if team is new then Scrum Master should be full time with team
As you mentioned, your team is completely new, you must have a Agile coach initially for Agile transformation.
As per practice, you need to estimate(size) during Backlog Refinement, yes in real-world scenario sometime we estimate in Sprint Planning 1. During Backlog Refinement you story should be READY. (Please check Definition of Ready)
 There is Spring Planning 2, where we create Tasks for Sprint Backlog Stories
it’s better to have face-to-face communication, if always not possible create a Chat group.

Agile Is Not a Silver Bullet, it takes time. Have to change mind-set and Culture.

Hope this will help initially, we can discuss further questions

10:29 am May 24, 2016

Paul,

What is your "role" with the team? Are you a member of the Development Team, or in another role?

If I understand correctly, you are concerned that the team is biting off more than they can chew for the upcoming sprint. Your concern stems from the reduced team capacity (two development team members < 100%).

Since this is a new team, they do not have an established velocity metric they can use to measure their "acceptance" against. If I were the Scrum Master, I would promote team acceptance of whatever amount of work they felt comfortable completing in the upcoming sprint. If the team stated they felt comfortable with 46 points in the upcoming sprint, who am I to object?

The team is best-positioned to understand the work needed and the time box it needs to be completed in. As a SM, I can point out to them their reduced capacity, but in the end it is their decision. They very well may complete all 46 points in the upcoming sprint. Who knows?

Also, I view a team's accepted offer as a "forecast" of work to be completed, not a commitment. Commitment speaks to traditional contract-based thinking.

There is one very important thing to keep in mind when embarking on Agile/Scrum. You need to be patient, and you need to be comfortable with failure. There is an old adage in Agile: "Failure is not an option. It is mandatory".

Traditional thinking is to view situations and try to remedy any perceived risk ahead of time. That is not the way of the Agile practitioner. The best path forward is to allow the team to make their own decisions, and learn from their mistakes. If they do not complete 46 points in the upcoming sprint, that can make for a good discussion in the Sprint Retrospective.

Failure creates the right conditions for effective change.

Good luck to you.

10:48 am May 24, 2016

Thanks guys for the replies.

My point is that the team did not decide on the 46 points... we've been running agile for a year in the company, and when I say the team is new, this particular group of people have been within an agile scrum team for 10 months or so.

We've seen that typically we can get to between 40 and 50 points in a sprint, with 3 devs and myself working full time in the sprint

I'm in QA, sorry I forgot to mention it.

I'm very interested in what you think of the PO's comments... and how the scrum team don't challenge even though they know they won't complete anywhere near the work within the sprint

His comment again was:

"If we don’t make it we don’t make it. The stories are small enough so that we can focus on closing each one off. It’s not the end of the world if we don’t get through the whole lot"

Is this a mistreatment of what a sprint is in the first place?
Should the team be speaking up and taking control of the planning?

10:58 am May 24, 2016

> I'm very interested in what you think of the PO's comments...
> and how the scrum team don't challenge even though they
> know they won't complete anywhere near the work within the sprint
>
> His comment again was:
>
> "If we don’t make it we don’t make it. The stories are small
> enough so that we can focus on closing each one off. It’s
> not the end of the world if we don’t get through the whole lot"
>
> Is this a mistreatment of what a sprint is in the first place?

What Sprint Goal has been agreed by the team with the Product Owner? Does it represent the sort of coherence that is described in the Scrum Guide?

If you don't have such a Sprint Goal, why not?

11:07 am May 24, 2016

Sprint Goal... you have me there!

We don't release at the end of every sprint... usually a release is 6 to 7 sprints long, with a wrap-up or pre-production time phase before releasing to the real world

So my assumption is the team is too quiet and there is a relaxed feeling coming from product owner, as its the very first sprint and there is no panic etc...

I just feel this is wrong and I want us to understand agile better! Why do we have a sprint with work we know we won't get to? What is so wrong with putting a 1/4 or more on the backlog and if we get to it we bring it in then?

11:22 am May 24, 2016

> Why do we have a sprint with work we know we won't get to?

Why do you have a so-called sprint at all, when a release is 6 to 7 "sprints" long, with a "wrap-up or pre-production time phase before releasing to the real world"?

That big-batch, delayed-release, leap-of-faith staged process is incompatible with Scrum and with sprinting. So where is the desire to change, and to work in a more agile way, actually coming from? Who in the organization actually wants to implement the Scrum Framework, as it is properly attested to in the Scrum Guide?

11:30 am May 24, 2016

There is certain steps we have to do post the final sprint... i.e. build a package (which is time consuming) then smoke test said package. Other tasks involve eye balling documentation and large performance tests within a package. These are tasks we unfortunately cannot commence until 2 to 3 weeks prior to going live.

Is it not possible to look beyond that, and aim to use the scrum model as most as possible to achieve a MVP at the end of each sprint, but respect the scrum dev team, velocity and the likes?

11:37 am May 24, 2016

> Is it not possible to look beyond that, and aim to use the scrum
> model as most as possible to achieve a MVP at the end of each
> sprint, but respect the scrum dev team, velocity and the likes?

It is possible to ignore the stipulation, as described in the Scrum Guide, to deliver Sprint Increments that are of release quality. You can call that "looking beyond" if you like...but the result certainly will not be Scrum, and using Scrum terms to describe the process is likely to cause misunderstanding about the benefits (if any) that will result.

11:45 am May 24, 2016

You see we are in an unfortunate position whereby we are native on another platform and don't own the entire development process... so we can have an excellent product that meets the goals of the release - which we aim to do by the last sprint, but we still have a period that is not dictated where we have necessary mandatory steps we have to abide by.

So please humor me guys as I'm looking for the best solution to an abnormal situation... where I feel scrum can answer most of the answers :-) I.e. Look at it again as if we didn't require these last few weeks or wrapping up etc, and a had a releasable product by last sprint. Again I know the aim to have a releasable product by the end of each sprint, but the cost to do so for us would be too high as to reiterate we don't own the entire dev process and must abide by others rules and release management\checks

I then ask, what do you think would help us?
(a) A sprint goal?
(b) Scrum dev team to own planning?
(c) Respect velocity?

Anything else?

Thanks

02:29 pm May 24, 2016

If I was in your position I would be looking to provide transparency over the waste that is being incurred through the team not owning their process, by the release of value being deferred, by not being clear on what "done" means, and by all the other things that currently stop you from implementing Scrum. Tools such as task boards and burndowns can help as can RAID logs and other things that show how risk is being accumulated.

In other words, you know that things aren't right, so you need to show how and why with supporting evidence. The first step in an agile transformation is often to provide basic transparency.

04:03 pm May 24, 2016

Paud,

Why do you believe the development team has provided a forecast for the upcoming sprint that they know they will not be able to fulfill?

What does it tell you when the team has remained silent when you've raised your concerns?

The typical velocity within your company over the past 10 months may be between 40-50 points, but that metric should never be used to forecast another team's productivity. Velocity is a completely subjective, team-specific metric. You cannot use velocity metrics gathered from other teams in an analogous or parametric estimation attempt to gauge another team's velocity, even if many of the members are the same.

Since this is the new team's first sprint, I would actually side somewhat with the PO. The objective is not to try and be perfect out of the gate. The PO is (hopefully) taking the position that the team has provided a forecast, they will work to the best of their ability to complete that forecast, and if for any reason they do not meet their forecast, it will be good to have a discussion about it at the end of the sprint.

06:40 pm May 24, 2016

No no you misread me sorry! This team the last team months have delivered around 40-50... this exact team :) sorry for the confusion!

06:42 pm May 24, 2016

Ten months not "team'' apologies for the typo above!

09:34 am May 25, 2016

Paud,

Help me understand these two statements from you that seem to contradict each other:

"Our team isn't mature enough yet to have an established approx figure of velocity."

"This team the last ten months have delivered around 40-50 (points)... this exact team."

10:06 am May 25, 2016

Posted By Timothy Baffa on 25 May 2016 09:34 AM
Paud,

Help me understand these two statements from you that seem to contradict each other:

"Our team isn't mature enough yet to have an established approx figure of velocity."

"This team the last ten months have delivered around 40-50 (points)... this exact team."

Sure. You're right they do. What I meant and what is a true reflection is...

During the last release at full resource capacity, we typically delivered around 40 to 50 points. We never narrowed it down much further. On one occurrence we got to nearly 65 but the stories were very small and we probably over estimated with two or three stories

The reality of it is, for 95% of the time, we deliver over 40 and under or very slightly over 50.

Sorry for the confusion..

02:22 pm May 25, 2016

Paud,

May I ask a couple follow-up questions then?

1) Did you voice your concern with the team over-committing during Sprint Planning 2? If so, what was said and what was the response? If not, why didn't you speak up?

2) Your team has an established velocity (over a 10-month period) between 40-50 story points. The team accepted 46 story points for the upcoming sprint. It seems they measured their acceptance against their past velocity, yes?

I'm still trying to understand where the disconnect is between you and the rest of the team.

Do you believe that the 46 points in the upcoming sprint is impossible to achieve? If it is not impossible, then do you trust the assessment of the rest of the team regarding their forecast?

08:48 am May 26, 2016

The PO is driving the content of the sprint
It snuck in there at full velocity for previous sprints... and the team didn't seem to question it or more so they just went along with it.

This morning the scrum master (who's new to the role and no formal training) suggested to de-clutter the sprint and take stories we know we won't get to out of the sprint, put them on the backlog and if we have time we'll pull them back into the sprint.

The PO laughed at it and said "we were too processy"

So to summarize
46 points is too much
The team didn't come up with this sprint
The scrum master didn't speak up at the time even though both him and the PO knew we would be low in resources AND we would have support issues drag as we just release the previous version a week ago

Thanks

09:36 am May 26, 2016

Paud,

The team must drive the content of the sprint. The PO can make their offer to the team, and there can be open discussion between the PO and the team regarding the offered items, but it must be the team that makes the determination of what can be completed in the upcoming sprint.

If this is not happening, it simply is not Scrum. Having an inexperienced Scrum Master, in addition to a Product Owner with little if any Scrum Training, makes the situation so much worse.

Keep in mind, it is not up to the Scrum Master to decide anything for the team. Their role is to support the team and reinforce proper Scrum practices. Sounds easy, but you've explained a situation where it isn't being done, and you're experiencing the subsequent pain points because of it.

06:31 pm May 26, 2016

Thank you all for the comments and guidance