Overfilling sprint but not overcomitting

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

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.

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?

> 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?

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?

> 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?

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?

> 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.

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

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.

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.

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

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

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."

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..

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?

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

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.

Thank you all for the comments and guidance