Meeting your goals by punting work items

[lisasolace]

We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.

We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.

Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the end
of a sprint?

[Ron Jeffries]

Hello, lisasolace. On Friday, December 1, 2006, at 1:44:11 PM, you

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.

If at the beginning of the sprint you sign up for N things, and then
at the end you punt M things, thus completing only N-M, how does it
"look like we're done with the items in [y]our backlog"?

Ron Jeffries
www.XProgramming.com
The man happy in his work is not the narrow specialist,
nor the well-rounded man, but the man who is doing
what he loves to do. You must fall in love with some activity.
--Richard P. Feynman

[lisasolace]

Hello, lisasolace. On Friday, December 1, 2006, at 1:44:11 PM, you

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.

If at the beginning of the sprint you sign up for N things, and then
at the end you punt M things, thus completing only N-M, how does it
"look like we're done with the items in [y]our backlog"?

...and therein lies the rub. We'll all agree on doing Nthings and we're
gungho on getting those Nthings done. In the process of working on
Nthings, we discover that we must add additional work items beyond the
Nthings and the priority for those additional work items has now
overtaken portions of those Nthings. Thus making the new group of work
items called Mthings. Well the team doesn't want to punt the difference
of Mthings-Nthings because, "what if we're able to get to them?"

I guess it just seems to me that this is a simple case of changing
requirements - and shouldn't I just be more vigilant about if something
comes into the sprint backlog, something should get booted out to make
room.

[Ron Jeffries]

Hello, lisasolace. On Friday, December 1, 2006, at 2:43:28 PM, you

Post by lisasolace
I guess it just seems to me that this is a simple case of changing
requirements - and shouldn't I just be more vigilant about if something
comes into the sprint backlog, something should get booted out to make
room.

Unless I'm mistaken, in Scrum the Sprint backlog does not change
during the Sprint. You might want to try working that way before
trying more advanced things.

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
-- after Mark Vaughn, Autoweek.

[Mike Cohn]

During sprint planning the team makes a commitment to deliver a set
of Product Backlog Items (PBIs) that they choose with the product
owner's guidance. During sprint planning they decompose those PBIs
into a set of tasks called the sprint backlog.

During the sprint work will emerge as the team's understanding of the
PBIs they've committed to emerges. This means that the team should
never fill up every known hour of available work--we know we'll
uncover new things to do. Those items are put on the sprint backlog.
An example I often give is of a team that selects a PBI about
"creating a demographic search screen." They talk with the product
who tells them the screen needs to allow searches on demographic
fields such as address, first name, last name, date of birth, etc.
Midway through the sprint the PO notices that the team has left out
searching on middle initial and tells the team it was intended as
part of the search. In most situations the team should be able to
accommodate this (it's a few hours; I'm assuming the team is roughly
"on track" when this is discovered). If the team is behind they may
say, "Sorry but we're behind. We can add middle initial if we defer
date of birth until next sprint." But what if the PO told the team,
"Uh, what you've got looks good but did I mention that demographic
searching includes geospatial searching by latitude and longitude? I
don't see that in here yet." In that case the team would probably
say, "No you didn't and perhaps we should have talked a _tiny bit_
more before we started but we clearly don't have room for that this
sprint. Please add it to the product backlog." (And then the four-
letter words would come out after the PO walked away to do so.)

Good Scrum teams acknowledge that their product backlog items
(ideally, IMO, as user stories in most cases) contain some amount of
uncertainty and always will. The cost of driving out 99% of
uncertainty is often greater than the cost of an occasional
misunderstanding. (And in this case I contend it would be.) Because
of this, we accept that the uncertainty of the PBI will only emerge
fully during the sprint. The team still commits to delivering the PBI
but does so with everyone aware that the commitment is to PBI as
generally understood. If that understanding shifts a little (we add
the middle initial) the team is still committed to it (subject to
being out of time) but when the understanding shifts dramatically
everyone needs to understand that the PBI will not be completed. This
can feel uncomfortable at first but some amount of this is desirable--
if it never happens then it is likely that too much effort is spent
in upfront understanding of the backlog.

Regards,

Mike Cohn
Author:
Agile Estimating and Planning
User Stories Applied
www.mountaingoatsoftware.com

Hello, lisasolace. On Friday, December 1, 2006, at 2:43:28 PM, you

Post by lisasolace
I guess it just seems to me that this is a simple case of changing
requirements - and shouldn't I just be more vigilant about if

something

Post by lisasolace
comes into the sprint backlog, something should get booted out to

make

Post by lisasolace
room.

Unless I'm mistaken, in Scrum the Sprint backlog does not change
during the Sprint. You might want to try working that way before
trying more advanced things.
Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
-- after Mark Vaughn, Autoweek.

[clintonnkeith]

Post by Ron Jeffries
Unless I'm mistaken, in Scrum the Sprint backlog does not change
during the Sprint. You might want to try working that way before
trying more advanced things.

The Sprint backlog (tasks) can be changed by the team. The Sprint goals
cannot.

[Ron Jeffries]

Hello, clintonnkeith. On Friday, December 1, 2006, at 8:14:41 PM,

Post by clintonnkeith

Post by Ron Jeffries
Unless I'm mistaken, in Scrum the Sprint backlog does not change
during the Sprint. You might want to try working that way before
trying more advanced things.

The Sprint backlog (tasks) can be changed by the team. The Sprint goals
cannot.

I had the mistaken impression that your team was not meeting its
sprint goals. Sorry.

Ron Jeffries
www.XProgramming.com
To follow the path:
Look to the master; Follow the master; Walk with the master;
See through the master; Become the master. -- Modern Zen Poem

[clintonnkeith]

Post by Ron Jeffries
Hello, clintonnkeith. On Friday, December 1, 2006, at 8:14:41 PM,

Post by clintonnkeith

Post by Ron Jeffries
Unless I'm mistaken, in Scrum the Sprint backlog does not change
during the Sprint. You might want to try working that way before
trying more advanced things.

The Sprint backlog (tasks) can be changed by the team. The Sprint goals
cannot.

I had the mistaken impression that your team was not meeting its
sprint goals. Sorry.

It had nothing to do with the question I was asking. You told Lisa
Solace that the "Sprint backlog does not change". You were mistaken.
Re-read the message you wrote:
http://groups.yahoo.com/group/scrumdevelopment/message/17764

[Ron Jeffries]

Hello, clintonnkeith. On Friday, December 1, 2006, at 9:20:21 PM,

Post by clintonnkeith
It had nothing to do with the question I was asking. You told Lisa
Solace that the "Sprint backlog does not change". You were mistaken.

I understand your point. I also understood Lisa to be saying that
the team was subject to external change, not just adding and
removing tasks.

And it seemed to me that they weren't getting done well, which does
suggest that perhaps less change would be desirable.

Ron Jeffries
www.XProgramming.com
Analysis kills spontaneity.
The grain once ground into flour germinates no more. -- Henri Amiel

[clintonnkeith]

Post by Ron Jeffries
Hello, clintonnkeith. On Friday, December 1, 2006, at 9:20:21 PM,

Post by clintonnkeith
It had nothing to do with the question I was asking. You told Lisa
Solace that the "Sprint backlog does not change". You were mistaken.

I understand your point. I also understood Lisa to be saying that
the team was subject to external change, not just adding and
removing tasks.
And it seemed to me that they weren't getting done well, which does
suggest that perhaps less change would be desirable.

Rigth. It sounds as though the "Sprint Goals" are changing:

Lisa wrote:
"In the process of working on Nthings, we discover that we must add
additional work items beyond the Nthings and the priority for those
additional work items has now overtaken portions of those Nthings"

Which shouldn't happen. The "Sprint backlog", list of tasks that the
team originally broke down to fullfill the Sprint goals can often
change as the team works on the goals. Limiting change there might
prevent the goals from being accomplished.

[Wolfgang Schulze Zachau]

Some of your statements sound a bit odd to me.

we don't always control our destiny when it comes to
having control over our backlog.
Which backlog? The team has no control over the product backlog at all. The
team has full control over the sprint backlog. If your team doesn't have
full control over the sprint backlog, then why not? What is happening there
?
Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog
Why is your sprint backlog ever growing ? Who is adding to it ?

I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.

Why is the team delivering stuff that was not planned? Do you do
retrospectives? What happens during the retrospectives?


Regards,

Wolfgang

[lisasolace]

Post by Wolfgang Schulze Zachau
Some of your statements sound a bit odd to me.
we don't always control our destiny when it comes to
having control over our backlog.
Which backlog? The team has no control over the product backlog at all. The
team has full control over the sprint backlog. If your team doesn't have
full control over the sprint backlog, then why not? What is happening there
?

The sprint backlog morphs every sprint. It may be because our product
owners never say no and we are a "service" oriented group. Or it may be
because each of the team members take on (or flesh out) additional work
that must be completed prior to the stories they have planned for the
current sprint. It could be that we're at the mercy of outside forces
having control over key pieces of dev process and can make or break our
sprint.) I'm sure it's bits of all of these things. In any case, we plan
our sprints with a 30% buffer to account for some of these issues.

Post by Wolfgang Schulze Zachau
Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog
Why is your sprint backlog ever growing ? Who is adding to it ?
I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.
Why is the team delivering stuff that was not planned? Do you do
retrospectives? What happens during the retrospectives?

We have very good retrospectives and have used what we've learned from
them to make better choices. Every sprint, we talk about not taking on
additional work - but this is the one lesson we never,ever,ever seem to
be able to apply. I hate to think I'm that incompetent, but when can you
beat them over the head with the lesson-book?

Post by Wolfgang Schulze Zachau
Regards,
Wolfgang

[Steven Gordon]

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.
We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.
Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the end
of a sprint?

Some of the key practices of Scrum are:
- A story is not finished if any of its tasks are not finished (no punting),
- Velocity for each sprint is determined by the value of just the
stories that were completely finished during the sprint,
- The velocity for the previouse sprints determines how much work is
planned for the next sprint, so that planning is calibrated to what
the team can actually accomplish. This reduces the number of
unfinished tasks each sprint and the need for punting.

Are you following the above practices?

Steve

[lisasolace]

Post by Steven Gordon

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.
We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.
Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the end
of a sprint?

- A story is not finished if any of its tasks are not finished (no punting),
- Velocity for each sprint is determined by the value of just the
stories that were completely finished during the sprint,
- The velocity for the previouse sprints determines how much work is
planned for the next sprint, so that planning is calibrated to what
the team can actually accomplish. This reduces the number of
unfinished tasks each sprint and the need for punting.
Are you following the above practices?
Steve

Our stories are very broad and oftentimes, not well defined. This is a
new theory for the team and we're having trouble integrating that
methodology into our continuous publishing content model. We know our
velocity in terms of single work items or tasks - and the team meets
their expected velocity. It just happens to be on different work items
than planned.

[Steven Gordon]

Post by Steven Gordon

Post by Steven Gordon

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with

the

Post by Steven Gordon

Post by lisasolace
items in our backlog.
We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but

that

Post by Steven Gordon

Post by lisasolace
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.
Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the

end

Post by Steven Gordon

Post by lisasolace
of a sprint?

- A story is not finished if any of its tasks are not finished (no

punting),

Post by Steven Gordon
- Velocity for each sprint is determined by the value of just the
stories that were completely finished during the sprint,
- The velocity for the previouse sprints determines how much work is
planned for the next sprint, so that planning is calibrated to what
the team can actually accomplish. This reduces the number of
unfinished tasks each sprint and the need for punting.
Are you following the above practices?
Steve

Our stories are very broad and oftentimes, not well defined. This is a
new theory for the team and we're having trouble integrating that
methodology into our continuous publishing content model. We know our
velocity in terms of single work items or tasks - and the team meets
their expected velocity. It just happens to be on different work items
than planned.

Then you just have to be explicit about what you did do and did not
do, and make sure the product owner approves the tradeoffs.

If your velocity is fairly steady and you can offer the product owner
the ability to swap work mid-sprint, I see no problem unless the
product owner is dissatisfied.

Steve

[dnicolet99]

Steve's suggestion sounds really good to me.

A few additional ideas come to mind. You say

1. you're delivering content (not software or some other sort of
engineered product)

2. there are frequent changes to stories, scope, priorities during the
sprint

3. you don't necessarily deliver anything into production at the end
of a sprint

4. stories are often very general at the outset of a sprint, and you
discover the details as you go along.

With those four points in mind, maybe it would be feasible to shorten
the length of the sprint.

Since the product isn't software, you don't have to worry about
squeezing any sort of formal QA testing in prior to the end of a
sprint. Essentially, you can just stop when the Product Owner feels
the story is done.

With a shorter sprint, all the changes that inevitably occur to story
scope and priorities would not have to be handled as on-the-fly
adjustments, but could be planned out a little better (even if
planning occurs faster and more frequently).

It doesn't sound as if there's any pressing need to align the sprints
with the approximately-monthly publication schedule. You could have
several short sprints between publication dates.

With shorter sprints, the effect of discovering the details of the
stories on the amount of work delivered in a given sprint would be
smaller, since you could "reset" and re-estimate more frequently. It's
often easier to deal with new information about requirements during
sprint planning than as a constant stream of changes mid-sprint.

Post by Steven Gordon

Post by Steven Gordon

Post by Steven Gordon

Post by lisasolace
We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with

the

Post by Steven Gordon

Post by lisasolace
items in our backlog.
We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but

that

Post by Steven Gordon

Post by lisasolace
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.
Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the

end

Post by Steven Gordon

Post by lisasolace
of a sprint?

- A story is not finished if any of its tasks are not finished (no

punting),

Post by Steven Gordon
- Velocity for each sprint is determined by the value of just the
stories that were completely finished during the sprint,
- The velocity for the previouse sprints determines how much work is
planned for the next sprint, so that planning is calibrated to what
the team can actually accomplish. This reduces the number of
unfinished tasks each sprint and the need for punting.
Are you following the above practices?
Steve

Our stories are very broad and oftentimes, not well defined. This is a
new theory for the team and we're having trouble integrating that
methodology into our continuous publishing content model. We know our
velocity in terms of single work items or tasks - and the team meets
their expected velocity. It just happens to be on different work items
than planned.

Then you just have to be explicit about what you did do and did not
do, and make sure the product owner approves the tradeoffs.
If your velocity is fairly steady and you can offer the product owner
the ability to swap work mid-sprint, I see no problem unless the
product owner is dissatisfied.
Steve

[Nicholas Cancelliere]

If you feel your stories are too broad then they probably are. Try
breaking them down further using INVEST (Individual, Negotiable,
Valuable, Estimate-able, Small and Testable).

When you say that people meet their velocity on work items different
than those planned - how are you calculating velocity? You only earn
credit for velocity by completing stories (requirements) that were
planned. Velocity is supposed to help you know what you can depend
on - when a developer says he can deliver 3 stories he actually does
so at the end of the timebox. Using the velocity from past sprints
helps you know what to predict in future knows - what the team
actually can accomplish based on empirical data.

Are you also prioritizing your sprint backlog? Developers ideally
work down the sprint backlog in 1 to N priority. If developers are
cherry picking you have a problem. If developers are working on
stories not even scheduled in the iteration you got a problem. Then
the question is why is this happening, is there something wrong with
your planning process? How do you currently plan your iterations
(sprints) and who attends them?

-Nick

Post by lisasolace
Our stories are very broad and oftentimes, not well defined. This is a
new theory for the team and we're having trouble integrating that
methodology into our continuous publishing content model. We know our
velocity in terms of single work items or tasks - and the team meets
their expected velocity. It just happens to be on different work items
than planned.

[Michael James]

Post by Steven Gordon
- A story is not finished if any of its tasks are not finished (no punting),

One nit here: A Product Backlog Item is done when the Product Owner and Team agree its
acceptance criteria are met. Pay attention to the story's definition of "done." Looking
exclusively at the task status is misleading because they easily become misaligned with the
story.

--mj