Estimation has been officially removed from Scrum (see new Scrum Guide). Good, because people are way too obsessed with it.
Check out this thread for a non-obsessed and effective approach. 1/n
Check out this thread for a non-obsessed and effective approach. 1/n
1. Slice a minimum functional implementation to deliver a useful capability to a customer
2. If number of stories > number delivered in last sprint, check again to see if you can slice further (many functional and technical slicing techniques for this)
2/n
2. If number of stories > number delivered in last sprint, check again to see if you can slice further (many functional and technical slicing techniques for this)
2/n
3. Be ok with the fact it might take 2 or 3 sprints to deliver something you want to actually release to a customer; don't bring more stories into a single sprint than you have proven you can deliver
3/n
3/n
4. If you complete the sprint goal early, and no other refactoring is required to maximise quality, you can pull in another story
Slicing stories this way enables you to count them rather than need an arbitrary abstraction like story points.
4/n
Slicing stories this way enables you to count them rather than need an arbitrary abstraction like story points.
4/n
Also, stories which add functionality to the product (and value to customers) is a currency both biz folks and devs alike understand. And will invariably be a more reliable predictor of capacity than SPs (calculate past 6 sprints' Coefficient of Variance for both to confirm).
5/5
5/5
PS - when I say "slice further", that doesn't mean "create MORE stories". That means be more precise about the target customer, capability and channel of an existing story such that you can reduce the scope of what you previously thought was your "minimum".
• • •
Missing some Tweet in this thread? You can try to
force a refresh
