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.

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

  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.

  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,


        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. Reblogged this on Agiliste convaincu and commented:
    Voila une définition que je défend déjà. Les sponsors ont trop souvent tendance à prendre le sprint backlog comme un engagement, une liste de choses que l’équipe s’engage à realiser.

  23. Pingback: Refactoring the Scrum Lexicon | Post Agilist

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

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

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

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

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

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

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

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

  32. Pingback: Scrum est un processus empirique, parfois décrit comme « l’art du possible ! | «DantotsuPM.com

  33. Pingback: Scrum, luck, and product development - Agile Socks

  34. Pingback: Scrum Master as Scrum Maester, a game of thrones

  35. Pingback: Studying for the PSM II exam – Thoughts on Software Management and Development

  36. Pingback: Three Sprint Burn-Down Charts of Dysfunctional Scrum Teams - Responsive Advisors

  37. “I wonder if we should change the word from ‘commit’ to ‘forecast?'”

    The key word might be “responsibility” which means to re-“pledge” or “honor”. What the customer desires us to honor is the total value of the promise rather than the wording of “commit” or “forecast” to merely the one value of “speed”.

    This is where the 2/3 rule helps. Total value is comprised of the three values of speed, price and quality yet we can only deliver 2/3 of these 3.We commit to a promise of value that entails more than just the value of speed that a sprint signifies. A ‘commit’ is implied to be for at least 2/3 of the three. It can be fast and cheap yet quality suffers. It can be quality and fast yet price rises. It can be cheap and high quality yet speed suffers.

    When reality intervenes, we let the customer check the box on 2/3 of our top priorities of speed, price and quality. Responding to the totality of the values of the “promise” is our responsibility beyond merely accountability to only one of the totality of the three values of the promise; namely “speed”. We have a choice to re-pledge a 2/3.

    Relating on the totality of value to our customer clearly expresses a mature perspective that our “commit” cannot predict the unpredictable and that their changes are priority and they have a choice to change priorities. Customers appreciate input into the breadth of value expressed in this way and our responsibility is to not sacrifice a customers changing perception of value and choice in the 2/3 at any moment in time.

    My $0.02 worth.

  38. Pingback: 经验主义—基于已知信息做决定-Scrum爱好者

  39. When you reference a Product Owner you use”he or she”, implying that a Product Owner could be either gender.
    When you reference weather forecaster you use “she”, implying that a weather forecaster is female.
    May I suggest you could substitute “they” in both scenarios, you will reduce complexity removing the gender and allow a more consistent read 😉

  40. Whatever you call it, what it is is a Plan. This is the plan – x units of work this sprint. Everyone knows plans change, but everyone also understands plans as the intended direction. Plans work toward goals, and we have a Sprint Goal. The items in the Sprint Backlog represent the plan to achieve it.

    Forecast and Commit carry unintended meanings or perceptions which are problematic.

    So why not call it a Sprint Plan. That would fit nicely as the output of Sprint Planning, and input to the Sprint itself.

  41. Idea of Forecast in scrum is good, but when we replace commitment with “forecast” the pledge thing will be gone. Sense of responsibility will be gone as there will not be a value of commitment.

  42. While the 5 values of Scrum clearly calls it out as “Commitment” ,why to use a new term “Forecast”?

    I believe, understanding of the definition quoted by Ken should be improved rather than using a new word

  43. I’d use the term “schedule” like in train schedule. Everyone understands that trains may occasionally be late but that it’s the fullest intention of the operators to run them as planned.

  44. Thanks for sharing the post, Good post.
    Comittment is to adhere to the comitted work agreed during the Sprint planning meeting that have been agreed by team to achieve the sprint goal. In case the changes are triggered due to Business priorities based on Legal, Regulatory, Urgent Market requriements, that would be the changed/ New commitments to achieve. New committments to be discussed with team and PO and then agreed upon.

  45. I do believe all of the ideas you have offered for your post. They’re really convincing and will certainly work. Still, the posts are very quick for newbies. May just you please prolong them a bit from subsequent time? Thanks for the post.

  46. Dear Ken,

    I was reading your Blog as part of the preparation for an upcoming Professional Agile Leadership certification, and I was astonished by the accuracy with which it captures the mindset of my PO. Then I read your last sentence, and though “Hey, didn’t the Scrum Guide change to “Forecast” already? And then I realised that this Blog is already 8 years old.
    Bottom line:
    Thank you, and all other agile though leaders for keeping the work up. Some of us might think: “Well this topic is 10 years old, everyone knows this.” But in reality really major players in business are still massively struggling with the adoption of an agile mindset. And small Scrum Masters like me are still struggling with coaching them into it.

    Your blog mattered today, keep the good work up!

  47. I can’t stop seeing in Scrum framework what I am learning on my meditation path. It seems to be an equivalent of Vipassana practice in an IT professionnal environment. It makes so much sense as it brings clarity moment by moment on what a team is experiencing and how we relate simply to the truth of the experience in order to learn, adapt ourselves to increase the value of the product by increasing our own satisfaction at work. I am grateful to discover this knowledge.

    “It is not the strongest of the species that survives,
    not the most intelligent that survives.
    It is the one that is the most adaptable to change.”

    ― Charles Darwin

  48. Pingback: In the Search for "The Art of the Possible" - Agile Coaching Hub

  49. Pingback: A Scrum Master’s Search for “The Art of the Possible” | Business Marketing Journal

  50. Pingback: A Scrum Master's Search for "The Art of the Possible" | Online Sales Guide Tips

  51. Yes, it is true that the team might not be able to deliver all that is committed and the should be just fine. But, think of this situation:
    There is a feature in the product that the team has committed in the next one month. With this, we and our competitor are releasing the feature at the same time. Due to some circumstances, the team could not deliver in a month and needs one more month.
    We are now behind our competitor by a month.

    What do you experienced product owners and agile practitioners do in this situation?
    Is it OK to deliver 50-60% of the commitment?

    • Ashwin , the situation you highlighted is not a normal circumstance . If I were the scrum master of this team , I would have motivated the team to provide detailed retrospection as to why we were not able to deliver committed stories . Was there very limited understanding of the functionality during sprint planning ? Were the stories groomed at the right granularity ? Once the team is able to answer all these questions themselves , they would be much better equipped to commit a realistic date .
      If the 50-60% of committed features tantamount to breaking the principle of “delivering value” then we simply defer it . If this 50-60% qualifies the criteria of value which the end user can derive , then we should let it go to production . This is a call the Product Owner will take . However , he cannot take a call on when will the complete feature be delivered . That’s for the team to decide. What he can do though , is reduce the priority of other User stories from the forthcoming sprint backlog.

    • Short feedback loops would have helped. If you have weekly sprints, it means that by the end of the month you will have some releasable part of the product and you can start introducing the idea to the market and getting feedback. It would be helpful if the product owner would identify and prioritise key features. The short feedback loops would help identify risks early and take action.

  52. Hi Ken. I completely agree with your thought on “commit” not being the same as “guarantee”, but I also believe that “forecast” is a bit soft of a term that implies less accountability. When deciding what to bring into the sprint, the team should truly believe that what they are taking in is achievable and should truly intend to deliver with the understanding that there’s always the risk that things outside their control may occasionally cause them to not meet the commitment. When the team does miss a commitment, it should be examined in retro to better understand what factors contributed and how these should be taken into account for future planning. I like the term “projection” for things far out on the backlog, “forecast” for things within the next several sprints, and “pledge” for things pulled into the current sprint.

  53. Pingback: The guilt of scrum. [draft] – alperen.be

  54. First of all, I absolutely loved this blog post! It really confirmed my understanding of some key concepts. Like many others on this thread, I find the terminology of “commit” vs “forecast” vs “insert suitable term here” intriguing.

    In the end, it is incumbent upon the Scrum Master to ensure that the organization is well coached so that all of the terminology of Scrum are well understood. This has been one of the challenges of organizational change to Scrum for as long as I can remember. If we don’t choose our wording intentionally AND make sure the entire organization understands what that terminology means, we risk failure in the adoption of Scrum. Just because the Scrum Team understands, doesn’t mean the rest of the organization does. I have seen this before…adoption by the Scrum Team does not equal adoption by the organization as a whole.

    There is a question on the PSM 1 about what happens if an organization does not adopt the Scrum terminology. Management may feel better, but it will be at the risk of the understanding of Scrum, the benefits of Scrum, and ultimately the organizational adoption of Scrum. This isn’t my original thought. This is a paraphrase from the Scrum Open Assessment question.

    I believe it is the responsibility of the Scrum Master(s) to coach the organization, and the PO(s), the Development Teams, and any stakeholders/others that are practicing Scrum to re-enforce Scrum throughout the organization.

    As for the terminology, Personally, I like “commit”. While not concrete, there is more weight behind it, whereas “forecast” gives the impression of offering a bit more wiggle room. I would rather have teams have a more firm target than a softer target each sprint. It offers more clarity.

  55. All of the smallest things in Scrum are significant. An organization that believes in the management prerogative believes that commit is a contract. That lead to Sprint reviews where the team was berated: “you committed, where is it”. So, just like waterfall the deliverable became a facade, quality a variable, and collaboration a sham.

    I also found that when an organization resisted Scrum terminology,, they were resisting Scrum.

    Best wishes after an observant post.

  56. I agree that “you committed to delivering feature x” can and is mis-used, however one of the values of Scrum is indeed commitment and I see in that a much stronger drive than simply forecasting.
    I would probably explain “commit” as “I will try with all my might as if what I am building was my own house (and if I don’t complete the build I am going to have to seep in the open)” but sometimes things are harder than expected and one has to deal with unforeseen issues.

  57. At the end of the day, it may all boil down to semantics and it may need take more to achieve a mindset change in the real world. However, given the true spirit of realism, practicality, transparency and empiricism , I would love to see it as “endeavo(u)r” > commit > forecast. Would love to hear comments and opposing views.

  58. Pingback: ¿La Agilidad puede ayudar a mi organización? - Software Evolutivo

  59. I totally agree with you Ken, unlike waterfall where they tend to see the end from the beginning which is always a setback and in most cases leads to white elephant projects. This approach gives the team a more relaxed atmosphere to do their best with what they have.

  60. Thanks Ken for this article. I really liked the part that says in waterfall, an estimate was a contract.
    Also the part that says “commitment” in Scrum is a pledge to do our best with what we have.

  61. I believe “commit” is a good word, if you understand it as “Before drifting off we will at least deliver what is in the sprint backlog”.

    I have always understood the commitment as a contract between the developers and the product owner letting the product owner know what will be worked on during the sprint, and the team know what to do first. Not a commitment à la “this will be finished by this date”. That is not agile at all.

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 )

Connecting to %s