Borderline between estimation and commitment
Joseph Syjuco
Ron Jeffries
wrote:
The team should always meet its date. The job of the Product Owner
is to manage scope to get the best possible product By The Date.
Ron Jeffries
www.XProgramming.com
You do ill if you praise, but worse if you censure,
what you do not understand. --Leonardo da Vinci
Alan Dayley
dates are on a calendar and fall somewhere relative to a particular
sprint end. Dates are not negotiated, scope at any given date is
negotiated. Dates don't move, scope "moves" in or out of the current
sprint.
Is the team completing their work at the end of each sprint? Meaning,
the work result is shippable?
Are estimates of scope by the end of a sprint tied to the actual
velocity or to someones wishes? (It might be the team members who are
wishful and unrealistic. It might be the company who is demanding
fixed scope in a fixed amount of time, which will not happen. It
might be everyone still ignoring reality and planning on heroics.)
The team should not be committing to more work (scope) in a sprint
than they are able to deliver. They know how much they can deliver
based on what they have been delivering, not on what they
optimistically think they can do.
The Product Owner should not be committing to more work (scope) to the
stakeholders than what the team can deliver. The PO knows what can be
delivered by what the team has actually done before.
The company needs to know the work (scope) that the team can actually
deliver, not what someone tells the team to deliver.
Don't commit to dates. Scrum operates in time boxes and the dates are
fixed. Commit to scope and get better at delivering what was
committed at the Sprint Planning meeting.
Alan
> --
> You received this message because you are subscribed to the Google Groups
> "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to
> scrumallianc...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scrumalliance?hl=en.
>
Marcos Müller
Im quiet interested in this discussion but for me looks like you tell one thing at the first 6 paragraphs and then in the last one you say another... I think i dont understand your last one!
You said and i agree that dates cant change so, you are already "commited" to this one by definition. But if you commit with the scope then you will have, scope, time and "money" fixed. Or im getting wrong what are you trying to say?!
thanks
Don't commit to dates. Scrum operates in time boxes and the dates are
fixed. Commit to scope and get better at delivering what was
committed at the Sprint Planning meeting.
--
Marcos Müller
Arquiteto da Informação - MAV Tecnologia
Bacharel em Sistemas de Informação - UFMG
marco...@gmail.com
Alan Dayley
One way to look at a project is through the "traditional" project
management view. One of the tenants of that view is what is sometimes
referred to as the "Iron Triangle" (See
http://en.wikipedia.org/wiki/Project_triangle#Project_Management_Triangle)
The triangle has three points of focus: Scope, schedule and cost.
Quality lives in the center to indicate that it does not change. The
other points are supposed to be negociable to allow for the needs as
the project progresses.
A very common is that most project managers, customers and management
attempt to define scope, schedule and cost up front and fix them, as a
commitment. This is fantasy as shown by industry and personal
experience.
A careful reading of the Agile Manifesto reveals that it holds cost
and schedule fixed, the team does not change (cost) and time box end
dates are known (schedule). What varies in Agile is scope. We know
the end date of the sprint or iteration and we know how much it costs
to work the project for that amount of time. What we don't know is
the exact amount of work that will be done.
That last sentence is scary for many. It is the "elephant in the
room" that all the Gantt charts in the world cannot make go away. The
more creative and innovative the domain and solution, the more true it
is that we don't know the amount of work that will be done. And
further into the future we gaze, the less we know of exactly what will
be done. This is the very reason Agile is scary and also why Agile
works!
If we don't know what will get done, how can we plan or commit to
deliver? How does the customer know they will have value from the
cost they spend?
- Don't gaze far into the murky future. Plan and execute in short
time boxes (Sprints) that end within the "horizon of predictability"
for you and your customer. (See
http://www.energizedwork.com/weblog/2006/01/planning-with-horizon-of.html)
- Because we don't know exactly the scope of the entire project, we
prioritize. Work on today's highest priority, most valuable stuff
now. That way, when the future date of end of money or sufficient
value is delivered, we know the most important work is done. The
highest value is completed, whatever date is declared as the end of
the project.
- At the end of the sprint, everything stated to be done, must be
done. As in shippable, can be deployed and used by the customer. The
customer gets value at the end of every sprint. The team is able to
change direction, adjust and adapt to the new environment and see to
the next horizon of predictability. If they don't get done, they
cannot be agile. Getting done is what allows agility.
- Measure what actually got done (i.e. the scope that was delivered).
Several measures of what actually got done gives velocity. Velocity
allows you to look further into the future, to move the horizon of
predictability further out. Use the measure of done as a basis for
planning the scope next sprint.
- Now the team can commit to a specific scope for the current sprint.
They know how much scope that can commit to by the end of the sprint.
For the time of the imminent sprint, they can fix scope, schedule and
cost. And they can commit to it on data, on what they have done.
So, the team doesn't commit to dates. The team commits to a specific
scope by the end date of the sprint. They commit that the product
will be shippable at the end of the sprint. They commit to being done
at the end of the sprint. And they commit to doing a certain amount
of scope every sprint. They need to measure the scope they are
capable of completing in a sprint so that they can be more confident
of their commitment. And as their commitment to scope per sprint
becomes more accurate, the company and customer can use this velocity
measure to be more confident that deliveries will be met. And the
customer is getting value each sprint, learning what is really
valuable and what is not, guiding the project sprint by sprint.
Alan
Joseph Syjuco
First off, my deepest appreciation to all your replies. Admittedly, I
haven't digested everything in (although I have read the replies a
couple of times already). Just to provide more context to our
scenario (its sort of a feature enhancement activity):
- Developer was doing another task when manager requested for an
estimate - he provided an end of business day deadline
- Developer squeezes it in his tasks and identifies some pages which
he considered as representative of the whole activity. Based from the
samples, he provided an estimate
- Estimate was echoed to the stakeholder
- During development, developer found a few things :
a.) Some pages are more complex then the ones he initially used for
estimates - thus will need more time
b.) Some blocker defects were found - need to fix else everything
will be useless
- Developer approaches manager that he needs more time due to the 2
items above - blocker defects (at least in developer's perspective is
not part of the original scope) and unexpected complexities
- Manager interprets this as lack of commitment and requests for more
sacrifice
- Developer is really disappointed since he has been spending extra
hours + weekend work to try and factor both in - unfortunately it was
not enough
Few items that I was able to derive from your posts so far (which
applied to our scenario):
- be realistic with the estimate - don't factor in extra hours
- commit to the dates - manage the scope
Glenn
the rules of Scrum. The Sprint end date is fixed. There is no
commitment to content. Of course meeting the commitment means many
things including getting backlog items done-done. If backlog items
remain undone at the end of a Sprint then they go back on the backlog.
Glenn
Alan Dayley
- The developer should not be doing estimates without the rest of the
team. Generally. Estimates from a team are much more accurate than
one person alone, even if that one person ends up doing most of the
work being estimated.
- The manager is by-passing the team and Scrum, as is the developer.
They should not do this.
- The developer should not be committing to things that require extra
work time. In fact, the developer is undermining the team by doing
so. In Agile the team commits to parties outside the team, not
individuals. Team members commit to each other.
- The manager is undermining the sprint planning process and derailing
the direction of strategic work. He should be interfacing with the
team through the Product Owner and the Product Backlog.
The scenario you describe is neither Scrum nor Agile. If it is a
common occurrence, it is a dysfunction and source of impediments, as
you have described.
A correction to your second summary point: Don't commit to dates. The
team commits to a specific scope by the end of the current sprint.
Dates are just markers of the end and beginnings of sprints.
Alan
John Clifford
I think the symptom here is the confusion between estimates and
commitments on both the manager's and developer's part. However, the
problem is that they're not adhering to Scrum.
First let's talk about the symptom. When the manager asked for an
estimate, he was really asking for a commitment. He wanted to know
when the work would be done, and he wanted to know it to a certainty
(shared with the stakeholder). The manager was putting his credibility
on the line... whether that was wise of him/her is something I'll
address further down. And, he evidently didn't give the developer
sufficient time to create an accurate estimate (if, in fact, the
developer actually understands how to create an accurate estimate).
When the developer provided an estimate, he was guessing as to the the
amount of effort required expressed as duration, e.g., man-hours or
man-days. For whatever reason, the developer did not fully understand
the scope of the problem before providing the estimate, and he made
the cardinal sin of providing an inaccurate estimate that I'd bet was
a single number, i.e., '3 man-days.' I'd bet that there was no
percentage of certainty, or a range, provided, e.g., '2-4 man-days' or
'3 man-days +/- 50%.'
I could go on for a while on the proper way to estimate, but that's
just addressing the symptom. The problem is the manager, and the
individual, aren't doing Scrum.
In Scrum, the manager wouldn't have asked an individual for an
estimate on a task. Instead, the Product Owner would have worked to
understand the stakeholder's need in terms of implemented
functionality that could be objectively verified and validated, and
then come to the team to create a valid estimate in a form that
correctly expressed the effort along with any uncertainty about that
effort and then derive a duration, in terms of numbers of sprints, via
the team's velocity.
In Scrum we recognize that estimates ARE guesses, and we know that
it's far better to be accurate than precise... to be approximately
right than precisely wrong.
In Scrum, we don't bring additional work into a sprint when we haven't
completed the originally-committed work, unless we abandon the sprint
and replan, or unless we have specifically and explicitly carved out
bandwidth from our capacity and reserved it for unplanned additional
work (a suboptimal approach).
In Scrum, managers/project managers/Scrum Masters don't bring work,
assign work, ask for estimates, etc., to team members. All work must
flow through the backlog, via the Product Owner, and only committed
items are worked on. The Scrum Master's job is to act as a referee and
coach, to ensure the Scrum process is being followed and to protect
the team from impediments including the impediment of urgent ad hoc
uncommitted work being dumped on team members.
So, my question to you is, why are you not following Scrum? Yes, this
would mean that the project manager/Scrum Master would be frustrated
because it would no longer be possible to task a single team member
with doing some additional urgent work... and this might also
frustrate certain stakeholders. However, perhaps this ad hoc urgent
work really is a problem that Scrum is exposing, and rather than
trying to figure out how to handle ad hoc crises better you might want
to ask why these ad hoc crises are happening in the first place, and
what you can do to eliminate them.
Michael James
> Instead, the Product Owner would have worked to
> understand the stakeholder's need in terms of implemented
> functionality that could be objectively verified and validated
I like the answers from John and Alan. One thing I'll add: An especially hard part of the Product Owner's job is to maximize the amount of work that won't be done. Schedule problems are prioritization problems.
Gustavo Cebrian Garcia
I Would like to talk about long term estimations and commitments ( sorry if I have not digested everything )
My main worry is about long-term estimations:
Consider this scenario:
We want to make a long-term estimation/guess ( 1 year ) because a date is very very very important for the business, and we need
to have a minimum functionality working for that date:
In this case, what a lot of managers would do, is to multiply what they think it is going to take by 2.
Does Agile speaks about this scenario? How far in time have you guys estimated in an agile way. Agilel is about finding the balance
between Agility and Predictability, is not it? I know you guys mention the predictability horizon, but I would like to hear about your experiences on
this and I will tell you mine.
Should I open another thread for this?
Gustavo.
Kurt Häusler
stories, will be done within a certain number of sprints, presumably
to meet some future release date or something.
When a team has completed a sprint, they have a velocity metric, of
how many story points they can deliver per sprint.
If the team goes ahead and does a rough estimate on all stories that
are of interest, then the PO can use those estimates combined with the
velocity to give a very rough estimate of which stories could be
delivered by which date.
Of course the further out the date, the rougher the estimate. And
stories further down on the prioritized product backlog should not
normally have as accurate estimates anyway.
Keep in mind that the velocity normally changes every sprint too, as
the team gets better at estimating, so these longer term estimates
could be continually revised.
Gustavo Cebrian Garcia
I often hear that Agile is just estimating for one Sprint.
Which is true as well, is that it is necessary to think whether a long-term date is necessary.
In summary, in the sprint 0, it is important to think whether a date is very important. You can do efforts on estimating
long term which are not going to be very useful as priorities can change.
If the priorities do not change an a long term date is important, then, we use the techniques mentioned ( velocity, etc )
In this scenario, I would say that identifying all the important tasks/features is important, and do spikes for all the necessary tasks
( if technology is not known )
I would say, that, many project managers need to understand that there are bugs and new requirements emerge. At the same time,
following Agile, the team has to commit and try to get things done and have a very good excuse when they do not get things done.
"Leave it for the next sprint" can be interpreted in many ways...
Gustavo.
Ron Jeffries
wrote:
> Consider this scenario:
> We want to make a long-term estimation/guess ( 1 year ) because a date is
> very very very important for the business, and we need
> to have a minimum functionality working for that date:
> In this case, what a lot of managers would do, is to multiply what they
> think it is going to take by 2.
> Does Agile speaks about this scenario? How far in time have you guys
> estimated in an agile way. Agilel is about finding the balance
> between Agility and Predictability, is not it? I know you guys mention the
> predictability horizon, but I would like to hear about your experiences on
> this and I will tell you mine.
Agility and predictability are not opposite ends of a stick. More
agility provides better predictability, not worse. Here's what I
recommend.
1. Choose a date to ship.
It does not matter how you do this. Quite possibly the best dates
are chosen by fiat. (So visit Fiat and find out how they do it.)
2. Ship the best possible product by that date.
This is done by the Product Owner selecting the features that
will, by the date, provide the best possible product. It works
best if done very collaboratively with the team, and with end
users.
Perfectly predictable, perfectly agile.
Ron Jeffries
www.XProgramming.com
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell
Ron Jeffries
wrote:
> Which is true as well, is that it is necessary to think whether a long-term
> date is necessary.
> In summary, in the sprint 0, it is important to think whether a date is very
> important. You can do efforts on estimating
> long term which are not going to be very useful as priorities can change.
Dates are very important, almost always. We do not hit dates by estimating. We hit dates by steering.
Ron Jeffries
www.XProgramming.com
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. -- Brian Kernighan
Gustavo Cebrian Garcia
I really like your comments. Let me add another dimension, and this is something I can not hear a lot in Agile
( Again, I am not saying this is not Agile )
-I have not heard about adding another team or adding another member to the team. I always hear about having a fixed team.
So, the tricky this is:
-Analysing the problem so that you get a better product by increasing the cost.
What is your experience on this? Is this entirealy true:
"A careful reading of the Agile Manifesto reveals that it holds cost
Thanks.
Gustavo.
--
Ron Jeffries
wrote:
> What is your experience on this? Is this entirealy true:
> "A careful reading of the Agile Manifesto reveals that it holds cost
> and schedule fixed, the team does not change (cost)" by Alan.
I'd like to hear Alan tell us where it says that. I don't think it
says that.
Ron Jeffries
www.XProgramming.com
Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
Steven Mak
understanding commitment:
http://blog.odd-e.com/yilv/2010/12/commitment-whats-your-confidence-level.html
Gustavo Cebrian Garcia
Previous email on this thread, maybe I misunderstood this. Alan ?
Gustavo.
--
Alan Dayley
Gustavo! I also love it when people question what I say because I get
to learn something.
Here is what I mean for the Agile Manifesto holding schedule and cost
constant. It's in the principles
(http://agilemanifesto.org/principles.html)
Schedule
Several of the principles define the goal of the product is ready for
use "early," "continous[ly]," "frequently" and "working." This means
that, beyond some threshold of minimum functionality, the product is
"always" usable and done. Once that threshold of must-have features
is met, the schedule is just a calendar. The amount of functionality
shipped, i.e. the scope shipped, is what varies. Pick a date and ship
the current scope.
Cost
Several of the Agile Manifesto principles point to a consistent team
membership: "work together daily," "motivated individuals,"
"environment and support they need and trust them," "face-to-face"
interaction and "the team reflects."
All of these points are the basis for maintaining a consistent team
membership for some length of time. For example, trust takes time to
create and is easily disrupted by a change of team membership. I
assume, perhaps wishfully, that knowledge of team building research,
social relationships and "The Mythical Man-Month" were part of the
input to these points. Agile literature supports my assumption with
many discussions about the deterimental effects of breaking up teams
by shuffling people around often.
For nearly all software projects and most other projects the highest
cost is payroll. So, if your team is not changing significantly over
time, cost is also not changing significantly.
Conclusion
So, I read that in agile practice, schedule and cost are not where
significant adjustment occurs. Scope is negociated. Specifically,
what features are included and which are not on a given date, is
adjusted based on the capacity of the team to do work and the needs of
the customer.
Is that too big of a leap?
Alan
Ron Jeffries
wrote:
> Here is what I mean for the Agile Manifesto holding schedule and cost
> constant. It's in the principles
> (http://agilemanifesto.org/principles.html)
> Schedule
> Several of the principles define the goal of the product is ready for
> use "early," "continous[ly]," "frequently" and "working." This means
> that, beyond some threshold of minimum functionality, the product is
> "always" usable and done. Once that threshold of must-have features
> is met, the schedule is just a calendar. The amount of functionality
> shipped, i.e. the scope shipped, is what varies. Pick a date and ship
> the current scope.
Always being ready enables hitting the date (or almost any given
date). It also enables making decisions to ship early (which is not
holding schedule and cost constant) or to defer shipping when some
threshold of features is done (which is not holding schedule and
cost constant).
The agile style enables decisions. It is my view, and I think it is
likely shared by many of the other authors, that the initial
schedule is often politically important. However, shipping well
ahead is often better (and does not hold schedule and cost
constant).
So I would have to say that we did not have holding schedule and
cost constant in mind, and that the manifesto does not imply that
schedule and cost should be held constant.
Ron Jeffries
www.XProgramming.com
The "rules" are ways of thinking, not ways to avoid thinking.
Alan Dayley
>
> Always being ready enables hitting the date (or almost any given
> date). It also enables making decisions to ship early (which is not
> holding schedule and cost constant) or to defer shipping when some
> threshold of features is done (which is not holding schedule and
> cost constant).
>
> The agile style enables decisions. It is my view, and I think it is
> likely shared by many of the other authors, that the initial
> schedule is often politically important. However, shipping well
> ahead is often better (and does not hold schedule and cost
> constant).
>
> So I would have to say that we did not have holding schedule and
> cost constant in mind, and that the manifesto does not imply that
> schedule and cost should be held constant.
Thanks for the clarification, Ron. An participant report on the
creation of the Agile Manifesto is far more correct than any
interpretation of the words. I agree with your points.
I failed to think of the full ramifications of "constant." I mean,
delivering early is a change to schedule and cost and I was not
thinking of that. Let me try again.
In more traditional frameworks (waterfall, chaotic, etc.) there is a
great deal of talk about "schedule slips" and "cost overruns." In
Agile these do not exist in the same way.
- The schedule does not slip, the amount of scope delivered by a
certain date changes from what was initially estimated.
- The cost does not overrun, the customer decides another sprint is
needed to get certain functionality that has been deemed worth the
additional cost. (This is still an overrun of the original budget, if
one was estimated. This overrun is softened by the fact that the work
of previous iterations is already deployed, creating value.)
Most important, the customer is not forced to agree to overrun because
the entire value of the product is not held hostage. There are no
statements like "We have to spend $XXX,XXX more for three more months
or the product is unusable." or "We can't finish early or we'll have
our budget for next year cut." ROI can be calculated per iteration
and work can stop once return is too small. The funding and schedule
can be agile too, instead of set in a read-only spreadsheet.
I'm having a hard time expressing myself on this topic. The bottom
line is that Agile allows discussions of schedule and cost to be easy,
in small iteration sized chunks because the main variable is scope.
Alan