In our previous post, we discussed doing smaller units of work, and doing no more of them than we need to fulfill an end-user's needs. This way, we get many things done, we deliver more quickly, and we develop less unneeded code (provided we get frequent feedback from users).
Fans of agile software development will recognize this as one of the axiomatic concepts behind agile, derivative of much earlier work on incremental and iterative development. Without incremental, iterative development and feedback, a process can hardly be said to be agile in any way whatsoever.
So we pick up the conversation today at that point:
When a team turns in an 8-point sprint/iteration/whatever, and are disappointed, they often look back over the week and realize that they under-estimated some of the stories which were harder than they looked, and that is the reason it was only 8 points. It should have been 15. In reaction, they give higher point-count estimates the next time. This kind of inflation isn't to deceive, but to better reflect reality and truth. But now the team turns in a more satisfying 15 point sprint, and exactly the same amount of work is being done.
That people misinterpret this as acceleration is not the team's intention. They merely are taking credit for the amount of work they actually did.
"Scoring points" and "having higher scores" classicly illustrates Goodhart's law. A measure (of completion rate) which is a reasonable measure, once chosen as a goal, ceases to be a valid measure.
You will hear development teams in scrum-like processes talking about work "blowing up." That means "like a balloon" not "like dynamite." There was some story that seemed like a 2-pointer, but turned out to take most of the sprint because there was more risk and uncertainty that anyone realized.
A story may have seemed simple: "add a discount code field." The product owner/manager/boss may have said: "that should only be a two-point story."
It seems easy. It should be easy to operate. What could be simpler? It's one field on a form, and you subtract some value from the total.
But these things are seldom simple. Marketing and accounting want tracking, and expiry for discounts, and demographic limits on the usage. Discounts need to appear on the customer's receipt as an indicator that they got a good deal from the company (marketing!). Discounts need to be represented in billing reports.
There may be special discounting reports used to measure the success of promotions. There may be anti-fraud ramifications.
Then someone decides that there should be many discount codes, and they should combine in some ways but not others. Now UX has to redesign the data entry screen, and there are complicated rules. Maybe those need a new microservice?
But it was a three-point story, right? This raises questions:
These are the wrong questions. They are based on a faulty assumption, and acting on them will only make things worse. We discussed curiosity spaces related to velocity in Part VI, which you may want to revisit at this time.
Ultimately, the thing to understand about teams using time boxes is that about the same amount of work is being done every week (barring absences and meetings and events on company time). Velocity is mostly illusion.
Consider Goodhart's law, curiosity, exploding stories, and inflation.
Then come back to join us for part IX.
Fans of agile software development will recognize this as one of the axiomatic concepts behind agile, derivative of much earlier work on incremental and iterative development. Without incremental, iterative development and feedback, a process can hardly be said to be agile in any way whatsoever.
So we pick up the conversation today at that point:
A: ...But I we get 23 points now, and they're as big as the 1/19th sized ones.People in an organization are constantly trying to satisfy their bosses. When organizations put pressure on developers to produce more points, developers start to find ways to score more points. There are some hilarious examples in Joshua Kerievsky's article on story points at the Industrial Logic blog. Sometimes it is intentional but not always.
B: That has two possible explanations.
A: What is the first explanation
B: That they're assigning more points to same-sized work: inflation.
A: Why would they do that?
When a team turns in an 8-point sprint/iteration/whatever, and are disappointed, they often look back over the week and realize that they under-estimated some of the stories which were harder than they looked, and that is the reason it was only 8 points. It should have been 15. In reaction, they give higher point-count estimates the next time. This kind of inflation isn't to deceive, but to better reflect reality and truth. But now the team turns in a more satisfying 15 point sprint, and exactly the same amount of work is being done.
That people misinterpret this as acceleration is not the team's intention. They merely are taking credit for the amount of work they actually did.
"Scoring points" and "having higher scores" classicly illustrates Goodhart's law. A measure (of completion rate) which is a reasonable measure, once chosen as a goal, ceases to be a valid measure.
You will hear development teams in scrum-like processes talking about work "blowing up." That means "like a balloon" not "like dynamite." There was some story that seemed like a 2-pointer, but turned out to take most of the sprint because there was more risk and uncertainty that anyone realized.
A story may have seemed simple: "add a discount code field." The product owner/manager/boss may have said: "that should only be a two-point story."
It seems easy. It should be easy to operate. What could be simpler? It's one field on a form, and you subtract some value from the total.
But these things are seldom simple. Marketing and accounting want tracking, and expiry for discounts, and demographic limits on the usage. Discounts need to appear on the customer's receipt as an indicator that they got a good deal from the company (marketing!). Discounts need to be represented in billing reports.
There may be special discounting reports used to measure the success of promotions. There may be anti-fraud ramifications.
Then someone decides that there should be many discount codes, and they should combine in some ways but not others. Now UX has to redesign the data entry screen, and there are complicated rules. Maybe those need a new microservice?
But it was a three-point story, right? This raises questions:
- Why did the team only turn in 5 points this sprint?
- What's WRONG with them?
- Why are they slowing down?
- What can we do to motivate them to go faster?
- Team X turned in 50 points compared to this team's 5, why are they 10x better?
- Does this team need a PIP?
These are the wrong questions. They are based on a faulty assumption, and acting on them will only make things worse. We discussed curiosity spaces related to velocity in Part VI, which you may want to revisit at this time.
Ultimately, the thing to understand about teams using time boxes is that about the same amount of work is being done every week (barring absences and meetings and events on company time). Velocity is mostly illusion.
Consider Goodhart's law, curiosity, exploding stories, and inflation.
Then come back to join us for part IX.
No comments:
Post a Comment