Don't prescribe adding estimates to PBIs
Estimates should be optional - many Scrum teams are able to work without using story points, hours or T-shirt sizes. They simply count their stories per sprint and slice as small as possible. This may be under the topic of #NoEstimates, bur my suggestion is not say don't use estimates, but instead make it an optional practice. Similar to how using a burn down chart was mandatory in the past but now not. It should be simply a tool. Making it optional also enhances the self organising property of the team.
Proposal: remove "estimate" from the line: "Product Backlog items have the attributes of a description, order, estimate and value." Ads "An estimate is optional if the team and Product Owner finds value in doing this."
FIRST – Scrum is for researching, creating, developing, delivering, etc of PRODUCTS. Not Projects. PMI needs to change the meaning of “P”.
The “manner” of making an estimate is optional.
When we order the product backlog, the amount of effort we believe is required becomes an “estimate.” It frequently changes as more is learned, including decomposition.
When I read the comments, I see many techniques for people managing their product backlog. All are good unless they are useless impediments. If not useless impediments, leave them alone.
PSM Guy commented
+1 David Sabine
Filip Beslic's comment highlights the trend that continues its momentum of Scrum being a re-branding of traditional project management. A few of the recent 2017 updates and related PST support will help further this issue.
Jeff Sutherland's comment is prescriptive regarding ordering, counter to the the idea of a framework and The Scrum Guide, and is aligned with traditional project management.
Filip. Where do get "scrum is a project" methodology?
make distinction between to estimate (we estimate even if not explicit) we do not need estimates (noun). The activity of estimating is useful, the estimates are often abused. a bit "no plan survives contact with the enemy" and then start a very useful planning session
Jeff Sutherland commented
Backlog is ordered by business value and this is ROI or something equivalent. This is value in the sense of revenue or impact divided by cost of doing the work.
Filip Beslic commented
Remember that scrum is a 'project' methodology. The purpose of a project is to fulfil a goal. In order for decision-makers to be able to make the trade-off between project A & project B, they still need some sort of estimate (transparancy).
I think you are confusing scrum with scrum-ban. For a service team, monitoring WIP is sufficient. But when you are doing projects, decision-makers need at all times to be able to decide: “does the project still make sense” (transparancy)? Is the ROI still positive? You can’t achieve that without any type of estimation.
Since scrum is result-orientated and focussed on business-value, thus user-stories, the only correct approach is to estimate user-stories. In addition, next to the ROI, decision-makers need transparency to make decisions: when to schedule training etc.. They thus need to know approximately when functionality will be delivered. Hence you need estimations.
Another benefit; business-value is not the only factor which determines the PO’s priority decision. He/she can also take into account the complexity of a story.
Alan Larimer commented
+1 for #NoManagement
If the team "simply count their stories per sprint and slice as small as possible" then they just put a "1" in the estimate attribute for all stories. Problem solved. No correction to the guide needed. Also this practice has so many questions and contexts that it doesn't fit in the general (lightweight) guide. What does it mean to "simply count and slice"? Do we ignore variance? How should a PBI be sliced such that it's "as small as possible"? In what way does it help the PO?
The "Ads" you're suggesting will most likely just create confusion and would probably require a guide on its own.
Finally, estimating is a good healthy practice. It's both natural and ubiquotous. The guide should not even indicate that it's optional. And as I said, it's easily fixed with existing attributes anyway.
David Sabine commented
Personally, I prefer #NoEstimates remain a protest and not formalized by removing the word from the Scrum Guide. It's a worthy cause and I support the movement. As a protest, it raises caution about the misuse of estimates. Estimates which are *not* misused, are extremely helpful while ordering a backlog.
For what it's worth, my personal stance on the matter is this:
- I'm pro estimates and pro #NoManagement.
- I'm pro #NoEstimates in environments with managers.