Estimation Got Removed from Scrum(medium.com)
medium.com
Estimation Got Removed from Scrum
https://medium.com/serious-scrum/how-estimation-got-removed-from-scrum-87ec0404f3c0
5 comments
> It no longer has remnants of output thinking and firmly underlined the importance of outcome thinking.
As far as I can see the article doesn't define these terms. Does anyone know what they mean in this context? Aren't "output" and "outcome" just two words for the same thing within the context of a software project to implement a feature or make a change?
As far as I can see the article doesn't define these terms. Does anyone know what they mean in this context? Aren't "output" and "outcome" just two words for the same thing within the context of a software project to implement a feature or make a change?
I'm not 100% sure but isn't it about focusing more on customer value instead of churning out features no one uses? So in summary:
- Output: what you produce, the features, bugfixes, documentation whatever
- Outcome: the actual value for the stakeholders. You could build one hugely important feature which would make the stakeholders love you but the output is still just 1.
- Output: what you produce, the features, bugfixes, documentation whatever
- Outcome: the actual value for the stakeholders. You could build one hugely important feature which would make the stakeholders love you but the output is still just 1.
Exactly. And outcome for many companies typically boils down to either an increase in revenue, or an increase in cost savings - but normally we use proxies for measuring those (like number of new sign ups, or decrease in churn, increase in CSAT etc).
It astounds me how many companies I’ve witnessed that loose sight of this and end up building feature after feature without even knowing if it’s having a positive (or negative!) impact.
I really like this approach, but a challenge I’ve encountered is successfully trying to measure that outcome and attribute it to the changes (outputs) that your team is making- either because their might be some lead time between output and outcome, or because you’re in a large organization with so many other teams making changes that might also be impacting the outcome you’re aiming to achieve.
It astounds me how many companies I’ve witnessed that loose sight of this and end up building feature after feature without even knowing if it’s having a positive (or negative!) impact.
I really like this approach, but a challenge I’ve encountered is successfully trying to measure that outcome and attribute it to the changes (outputs) that your team is making- either because their might be some lead time between output and outcome, or because you’re in a large organization with so many other teams making changes that might also be impacting the outcome you’re aiming to achieve.
Should be: Removed from the Scrum guide. Most places are still happily using story points as a form of measuring time.
Doesn't really matter what the book says when both places and consultants en masse say it is B and not A.
Doesn't really matter what the book says when both places and consultants en masse say it is B and not A.
For example, between 2011 and 2020 the Product Backlog items lost the estimate: it means that if that feature is late it is the fault of a struggling developer, not of a superficial planner.