Does Size Really Matter?
Sizing PBIs in Scrum
“Everyone has a butt. No matter what size it is, you can work it.” — Big Freedia
The work needed to improve the product is defined in the Product Backlog: Product Backlog Items (PBIs). These PBIs may be of various sizes. These items may be refined into smaller items, yet they should remain large enough to still be of value to stakeholders. They should be small enough that developers can get them “done” within a Sprint.
Therefore, at the very least, Developers determine if an item fits in a Sprint and if it’ll deliver value.
Scrum Teams using Kanban can also use another anchor for sizing: Will it fit our Service Level Expectation (SLE), or not?
Let’s say a Scrum Team learns it completed 85% of its items within five days or less. Can Developers, to the best of their knowledge, estimate if a PBI can be resolved within five days or less? If not, they may simply size it as ‘too big’.
‘Fit’ or ‘no fit’ may be too binary. Context may require multiple levels of sizing. Sizes can be relative. Developers estimate whether or not an item is expected to be more work and, or more…
