A normal person would expect that sharing free content doesn’t create controversy. Well this normal person is wrong. A couple of weeks back I shared a report on #NoEstimates based on my adoption experience in the last 2-3 years.
I got some thanks, some praise, but mainly aggravation. I had noticed this trend before when tweeting about #NoEstimates, when a group of individuals taunted me with replies and links to their articles that according to them clearly demonstrated that estimates are absolutely necessary and vital for the universe not to implode.
Examples are… People talking to each other by replying to my tweets as if I wasn’t there:
@PeterKretzman and it appears from his TWTR tage line "like breaking peoples balls." a professional Provocateur @cobrakaiagile @augeva
— Glen B. Alleman, MSSM, Vietnam 69-70 (@galleman) February 6, 2016
Others saying that what I did had no value and I was trying to sell something :-(
@augeva There's little or no value in a little-but-no-substance evangelistic testimonial. It reeks of sales. @henebb
— Peter Kretzman (@PeterKretzman) February 5, 2016
Apparently all this because while looking into my crystal ball I didn’t predict I had to answer this plethora of questions:
@henebb @augeva Or, what the problem domain was, the value at risk, the size & nature of the team, and lots more. pic.twitter.com/Kx0Xd4Z6hM
— Peter Kretzman (@PeterKretzman) February 5, 2016
Even though Mr. Kretzman refused to explain why I should answer those questions as part of a free experience report, today I feel generous and I am going to answer them, ONE BY ONE.
Q1: What do you specifically mean by NoEstimates in your case?
I mean that our development teams don’t lock themselves in a meeting room shooting numbers after perceived size of a piece of work, they save that time and focus on breaking the work down in less complex pieces.
Q2: What were the details of the domain and situation (value at risk, type of project, technologies employed, size and duration of effort, governance model, industry, team size)?
The domain is sports betting and gaming. The value at risk is the value of a bookmaker with well over 8 billion euro turnover. The type of project is all projects, from a simple web site to a complex trading platform. Technologies are web and mobile. All sizes and all durations, from a one day job to a never ending one. Governance model? What’s got to do with estimates? Industry as above, sports betting and gaming. Individual delivery teams are normally from 5 to 12 people, more than one team can work on the same product.
Q3: Was this one team among many in the company?
We started with one team, when we saw it worked we adopted it to one department, then to the whole company. Experiment, measure, learn.
Q4: Was it working on a mission critical product?
Yes. And now on every product.
Q5: When stories were chosen, how’d that process actually work? When stories were sliced, how’d that process actually work?
Defining a meaningful vertical slice of value to deliver and breaking down its user stories are challenging exercises that take time and practice to master. Our teams are always improving using good practices and discovering new ones. As you can imagine I can’t explain it to you in 2 lines on this post, but if you are interested I believe that in a couple of months I can get one of your teams going. My special fee for you is $850/hr expenses excluded.
Q6: Did you forecast completion dates at all or keep slicing and delivering chunk by chunk?
We try to educate our business partners that it is not about scope, time and budget, but about delivering products that matter. Scope is meaningless, we try to talk in terms of customer value discovery.
To facilitate the conversations with our partners we also show trends that can be used as forecast.
| Reference: | #NoEstimates episode 2 – THE ANSWERS from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
For those who insist that business partners actually DO care about scope + time + budget, I will point out that the OP has said that this is an established team (BUDGET) dedicated to delivering the next chunks of functionality (SCOPE) that can be delivered in each sprint (TIME). The emphasis of his anecdote was on how just-in-time discovery of pieces of functionality (scope) delivers continuous value to the business process owner and that his team does this by avoiding wasting time trying to estimate unknowns too far in the future. If his business process owner is so happy with… Read more »