Empiricism, the act of making decisions based on what is

Empiricism is the act of making decisions based on what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

A Product Owner plans a release based on all current information. He or she lays out the goals, the features and capabilities that will deliver those goals, and the probable cost and date of delivery. From that point on, the Product Owner’s job is to assess what is possible given the Team’s capabilities, and to make the best decisions to reach the desired goal. Given the nature of technology, markets, requirements, and people, trade-offs are made. Sometimes the goal cannot be reached for a reasonable price. Sometimes the goal will be reached, but in a way different from what the Product Owner initially intended. This is empiricism in action.

The Team (of developers) on the Scrum Team does the same. It meets with the Product Owner and assesses what the Product Owner views as the most important things to do next. If done, these will move the emergent product in the best direction toward the desired goal. The Team selects as much as it believes it can do over the upcoming Sprint. The cost of the team and Sprint length are fixed. Only the amount of Product Backlog selected can vary.  The Product Owner and Team often define a goal for the Sprint. This is a subset of the release goal.

When the Team selects Product Backlog Items in a Sprint Planning meeting, it commits to do it during the Sprint.  A definition of “commit” is:

To bind or obligate, as by pledge or assurance; pledge: to commit oneself to a promise; to be committed to a course of action. (www.dictionary.com)

This conforms to my intentions of the word commit, which is a pledge, a commitment to a course of action.

However, many Scrum Teams use the word commit as if it were a “guarantee.” This is a residue of waterfall, where an estimate was a contract. However, it still rings in the heads of product owners and developers. I have found team after team that feels they have to do anything to deliver their commitment. The usual victim is quality.

I wonder if we should change the word from “commit” to “forecast?” That might elicit the impression of the weather forecaster attempting to provide us with the best possible information. She works with what is known and the science of meteorology. She doesn’t provide a guarantee, but something that we can work with to make decisions. We find forecasts used by sales organizations as well. Perhaps this clarification will help us understand that a “commitment” in Scrum is a pledge to do our best with what we have.

53 thoughts on “Empiricism, the act of making decisions based on what is

  1. It sounds like you’ve used the term commit correctly. Any misinterpretation is probably WaterRUP baggage as you say. However, there is a lot of WaterRUP baggage in the language used by the Scrum Guide — I don’t really see how you can totally get away from it.

    I don’t know about the rest of the world, but in the U.S. at least, I don’t think images of a weather forecaster are going to breed confidence from users. In fact, it might breed false confidence, as “we can forecast the future….”

    Also from dictionary.com:

    –verb (used with object)
    1.
    to predict (a future condition or occurrence); calculate in advance: to forecast a heavy snowfall; to forecast lower interest rates…

    The thing is, we can’t predict the future. Rather than change the terminology to something that is not that much better, how about we just add a sentence that says something like?

    “When we say commit, we mean the Scrum Team puts a good faith effort towards delivering what they committed to trying to deliver. However, as in all complex product development, things change quickly, so we also agree to collaborate any time conditions change such that we can’t meet our previous commitments. We will then make new commitments, and so on.”

    Anyway, just off the cuff reaction.

  2. sprint commitment->forecast makes sense. The bigger problem is the language and negotiation of commitments with the business.

    A challenge I see is some cases biz still needs a commitment to a date. The language can probably be we can forecast what we will have by that date.

    For example we are launching a new shipping partner. When do you think you can be ready with the adjustments needed to support that? Now after a date is set there can be a scope buffer or time buffer. Within the sprints the model you outline will work great.

    There can also be a separate lower priority work that can be scoped out during that time to allow for growth in the scope of the committed work.

    • You understand that the real question is how you ever committed to a date using waterfall??
      There are many ways to rapidly commit to a date/cost in Scrum. We cover them in the Foundations course and the Scrum Master course at Scrum.org. These techniques provide a much more accurate date/cost than waterfall for 1/6 the up front planning effort.
      Ken

  3. Hi Ken,

    I like the word you used last – Pledge. I seem to remember that we used to word it as “make a commitment” rather than “commit”. That seems to be a slightly “better” wording.

    Of course, as Scrum teams, the one true commitment should be towards doing our best.

  4. On the one hand it does seem better to reflect a possibility/prediction than a promise/contract. That’s reality after all.
    On the other hand it is sort of fuzzy and leaves room to interpret it as unreliable.
    There is probably not one word that is completely self-explanatory and ‘one-click’ comprehensible.
    I would go for the best reflection of empiricism, i.e. … forecast.
    Gunther

  5. Hi,

    Thanks Ken to share your thoughts about this. I agree with you that the word “commitment” has been very badly understood during the last ten years.

    I use the word “commit” in statements like :
    – The team commits to deliver only done increments
    – The team commits to be transparent with the increment by not delivering any undone feature
    – …

    I use the word “selection” to describe the set of PBIs that a Team selects during the Sprint planning.

    Makes sense? Consider that I’m not a native English speaker😉

  6. Good points about the meaning of commitment. And I like this.
    > I wonder if we should change the word from “commit” to “forecast?
    I shall experiment with using that term. I think it’ll be very helpful to help maintain a sense of reality.

  7. You mention that … “This is a residue of waterfall, where an estimate was a contract.” I personally feel that this is more institutional thinking brought about by the “software engineering” paradigm.

    The sooner the software community moves away from this paradigm and more towards alternative view points (such as software as craftsmanship, or art, or music, or theatre, or CAS) the better we will understand the true nature of creative, collaborative work. Trying to define emergent work before that work has started is an exercise in crystal ball gazing.

    Enjoyable and thought provoking post! Thanks!

  8. I like commit. We make many commitments in our lives, and we strive to fulfill these commitments. Sometimes we fail, but I think most of us take commitment very seriously. Forecasting, on the other hand, we probably don’t take as seriously. Like forecasting the weather. Sometimes right, sometimes wrong. No big deal.

    I think we want teams to commit. To be serious and do their utmost to fulfill the commitment. We might not always succeed but by using a much less forceful term I think we would be setting to low a standard. Set the bar high, and help teams aspire to be great. Set the bar lower, and the best we’ll get is good.

    • I see the change of language as a movement towards a change of mind. I agree that commit is a fine word, and making commitments is valuable. The trouble is the word has become abused, and its meaning changed to suit the command and control culture in which it has been used. By introducing a word like forecast we’d be bringing people back to a sense of reality about what “commit” /actually/ means. There is something here about seeking a common language between customers and team.

      • > The trouble is the word has become abused,

        Tobias,

        Isn’t this true of a lot of words in software and Scrum? By this logic, we need to replace every word that has been abused by WaterRUP and C&C in the past.

        I wish we’d work harder on changing the mindset and less hard on changing the prose.

        Besides, wasn’t the “Sprint Goal” a way of making our “commitment line” a little fuzzier?

        When I coach PO’s on Release Dates, I encourage them to show a range based on low, average, and high velocity. Why can’t we do the same thing at the Sprint Level?

        Honestly, I think we need to clean our own house on this one.

  9. @charlesbradley. I agree with Tobias. Because, as Tobias says, this is a change not just for the sake of it, but a way of inducing a mindshift, more emphasizing that it’s about measuring reality rather than contracting the future.
    And you can hardly say that evolutions are being limited to the prose, as Scrum.org has first launched the program for Scrum Developers. And -most recently- created a PO program aiming at bringing empirical thinking to Product People. Hopefully a new generation of Agile Product Managers will emerge and see Scrum as a tool to increase their company’s Business Agility. I believe the latter to have the potential of giving Agile/Scrum adoption a serious additional boost.

    • Gunther,

      I can’t disagree with too much of what you said, I just think changing a word from “commit” to “forecast” is not the best way to achieve the mindshift. I also do not think training and certification is the best way to achieve the mindshift(unless your motive is to profit from the training and certification).

      Here are some other possible suggestions for mindshift implementation on this topic:
      1. Presentations by Ken and others at user groups on the Scrum mindshift changes.
      2. A whitepaper/topic article/FAQ written by Scrum.org – call it whatever you want on certain Scrum topics. (Apparently, the text in the Scrum guide alone has been unsuccessful at making the mindshift clear). These “Scrum topic papers” can be explanations of things mentioned in the Scrum Guide that might need further explanation.

      • > I just think changing a word from “commit” to “forecast” is not the best way to achieve the mindshift.
        I recently changed the word “meeting” to “conversation” and have been amazed at how much difference it makes to the way people think about what they are doing, and thus how they behave. Language matters. I believe greatly.

  10. I agree that language matters. I just don’t agree with changing the word commit to forecast in the Scrum Guide is the best way to achieve the mindshift. I gave a couple of examples of what I believe would be better ways, though I think there might even be better ways than I described.

    • Oh, in fact I wasn’t referring to the Scrum Guide. I have no opinion on that. I mean using new language as part of the conversation, e.g. “what is this team’s forecast for the next sprint?” and then perhaps, “does that feel like a commitment or a fond hope?”.

      After all, it’s about dialog, not documents, right?😉

      • True, but you’re not going to get very far with the mindshift if the Scrum Guide says “commit” but some blog post calls it a “forecast.” Language matters, remember?

  11. @charlesbradley Again, it’s not about what a blog post or any other document says. There are hundreds of documents, blog posts and books that tell people how to do Scrum, they won’t all be aligned, and no one document is definitive, no matter what its author claims. What matters in the end is the conversations you have in real life with real people. These new conversations, followed by new actions is what will create the mindshift.

    • I don’t agree. This blog post will have next to zero impact unless it’s supported by other artifact changes or the equivalent of a widespread PR campaign. Ken’s blogs are fairly widely seen, but this one blog post is not nearly enough to make a mindshift in the community.

      • A mindshift doesn’t occur through blog posts, books, PR campaigns or other broadcasts, it comes about one person, or one team at a time, and spreads to groups, organizations and beyond in a viral fashion. I am not seeking to have the whole Agile community agree on the use of this term over that term, or to all be in agreement. I don’t see that as helpful, or even interesting.

        I guess we have different goals. My goal is to introduce new language to the teams I work with to help them see the world differently. To that end I find Ken’s suggestion of using “forecast” instead of “commitment” to be a useful suggestion.

  12. Above, I said this:

    / snip /
    Here are some other possible suggestions for mindshift implementation on this topic:
    1. Presentations by Ken and others at user groups on the Scrum mindshift changes.
    2. A whitepaper/topic article/FAQ written by Scrum.org – call it whatever you want on certain Scrum topics. (Apparently, the text in the Scrum guide alone has been unsuccessful at making the mindshift clear). These “Scrum topic papers” can be explanations of things mentioned in the Scrum Guide that might need further explanation.
    / snip /

    It dawned on me tonight that one of the reasons Mike Cohn has had such a profound effect on the Scrum community is because he has essentially done all of the above. I think there is something to be learned there.

  13. I have experienced similar problems with the commitment concept. And I have experienced other problems with the forecast concept: the team doesn’t achieve what it planned and reacts with “that is not our problem, its the fault of …” or “doesn’t matter, forecasts are just fuzzy”

    What I like about the commitment concept is that it creates a constraint for self organization of the team during the sprint. And the team gets hard-to-ignore feedback when it doesn’t achieved its commitment.

    I think that changing from commitment to forecast will change something but I am not sure that this change would be an improvement.

    Based on my experience I like commitment more than forecast.

  14. Hi Ken – had wished there was more time to talk about this at the breakfast event you gave in NYC 5/5.

    “Forecast” seems a great word to use for expectations setting for those external to the team, but so far I think I lean towards “commitment” within the team itself.

    I had always understood that while “commitment” explicitly meant making the sprint commitment, implicitly it signifies committing oneself to “be a part of the team” through that commitment. For me (a noob) it is a renewal of the commitment to work in a particular Agile way rather than off by oneself in a cube doing stuff for weeks on end and reporting into a spreadsheet that gets reported in at a status meeting that talks about everything we’re behind on.

    So, in order to “be a part of the team,” the commitment actually becomes a commitment to engaging in self-directed work and to inspect-and-adapt. It becomes much more about not just being “involved” in a team, but being “committed to” a project team and, from that, a sense of urgency arising, of wanting to “get something to done” with the team. I think of John Kotter’s talk here: http://bit.ly/lR2Paa

    Of course, as we make commitments and start working, we’ll discover stuff as we unravel trying to get it to work and that stuff we unravel may delay the end point. But better to have that sense of urgency and goal in my mind (as a team member), of enthusiasm to meet a goal, rather than drift off into a forecast. I may never get anything to done that way.🙂

    For those new to a team, or new to Scrum, might be better to evolve into “forecasts” once we firmly establish we’re really committed to the team?

  15. Pingback: Forecast or commit? | Process Revolution

  16. Pingback: Refactoring the Scrum Lexicon | Jordan Bortz's Software Architecture Blog

  17. To commit is to pledge, which in turn is to offer a solemn promise (also from Dictionary.com). Offering a commitment tells me that you are going to do what you can to deliver the value that I require.

    It isn’t a blind commitment. At the start of the Sprint we will agree what that commitment should be.

    But after you’ve made that commitment, if you deliver something that is sub-standard, then I reserve the right to be thoroughly annoyed.

    Particularly if you keep on doing it.

    So my suggestion is not that we “change the word” but rather we look long and hard at the way we estimate, the way we manage our time, how we judge our – and our team’s – abilities – and we make the RIGHT commitments.

  18. I think you should leave the term, with the original meaning, as it is. You mention that quality appears to be impacted. That must mean the definition of ‘Done’ (i.e. the Conditions of Acceptance’) have not been fully defined or met. There should be no reason for quality to suffer provided ‘done’ embodies the quality criteria. So what gives? Answer: low business value items in the sprint – they get moved to the next sprint.

    The result is the team delivers working code of acceptable quality, and they feel good about it. The Product Manager gets most of his features working solidly (and therefore demonstrable/potentially shippable) and – here’s the key – the team’s velocity is reduced, but now correctly reflected. The process is therefore self-correcting and the team’s performance should converge on a velocity that represents deliverery of good quality code.

  19. Pingback: l’empirisme ou l’acte de prendre des décisions basé sur ce qui est « DantotsuPM.com

  20. After reading this post and the comments I am led to believe that one should never commit to a set of work. A team can forecast what they can get done, but no committing to get a specific set of work done.

    Commitments belong to goals. I also like the idea of forecasting specific blocks of work for a sprint. If a team does commit to a block of work should the team be expected to get it done? What if the team got done what it committed to 60% of the time? Which means the team did not meet their commitment 40% of the time. Is this acceptable? Should this % (commitment met) improve over time or should we expect it to remain the same?

    If my boss asked me for something 10 times and I told him I could do 6 and then did 3, should the boss be able to count on me? If it happened again am I seen as reliable? Or should I tell him “I forecast I can do 6” and he’d be fine with 3. Has anyone worked for a manger like this?

    My point is if a team commits to a chunk of work, the team should be expected to deliver a majority of the time.

    When a commitment is made it should be met, this is how business functions. If it can not be met we should dig up the reasons, retrospect and improve.

    So moving forward we will commit to goals and not to stories.

    • I think you and your boss should reset your expectations. You clearly are a “3” type of guy, so that is what should be expected and forecast. If you do “3”, why would you keep saying that you are a “6?” Ken

      • this is were capacity and velocity help you forecast what can be achieved.

        But, I do think that if commitment is that important and if results and expectations must absolutely match then you will be scared of trying to improve and always be very conservative.
        Scrum is aimed to help team improve, if not accomplish what was commited is not an option, you wont improve and you ll miss an important part of scrum.

  21. I fully agree with this change in the definition.
    Because of this “commitment”, upper management tend to consider the sprint backlog as the work that has to and will be done during the sprint. They dont see it as a goal the team will do its best to achieve.
    This is not what the team commit to do but it think it can do during the sprint.

  22. Pingback: Refactoring the Scrum Lexicon | Post Agilist

  23. Magnificent beat ! I would like to apprentice while you amend your website, how could i subscribe for
    a blog website? The account aided me a acceptable deal. I had
    been a little bit acquainted of this your broadcast offered bright clear idea

  24. Great beat ! I wish to apprentice while you amend
    your web site, how could i subscribe for a blog website?

    The account aided me a acceptable deal. I had been tiny bit
    acquainted of this your broadcast offered bright clear concept

  25. It’s a shame you don’t have a donate button! I’d definitely donate to this fantastic blog! I guess for now i’ll settle for bookmarking and adding your RSS feed
    to my Google account. I look forward to new updates and will share this
    website with my Facebook group. Chat soon!

  26. Hey There. I found your blog using msn. This is a really well
    written article. I will be sure to bookmark it and come back to read more of your
    useful information. Thanks for the post. I’ll definitely return.

  27. I like the helpful information you provide in your articles.
    I’ll bookmark your weblog and check again right here frequently. I am quite sure I will be told lots of new stuff right here! Best of luck for the next!

  28. Does your website have a contact page? I’m having problems locating it but, I’d like to shoot
    you an email. I’ve got some creative ideas for your blog you might be
    interested in hearing. Either way, great blog and I look forward to seeing it
    develop over time.

  29. Pingback: Scrum Foundations – Empiricism, Self Organization, Prioritisation, Rhythm and Collaboration | Agile Jottings

  30. Pingback: Un equipo comprometido (Parte I) | Scrum una nueva forma de pensar

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s