At the risk of being excommunicated from the Agile community: We can insist that story points should be a measure of relative effort as much as we want, but everyone (and I mean all of us) convert effort into time, since effort/capacity is duration. What’s the golden story against which we rank the relative effort of all other stories? How is the effort of a story about setting up SQL tables relevant to effort estimation for a data science story? What about new team members who just finished with a team that had a completely different golden story representing one story point?
I like to use a natural estimation approach, with an estimating technique everyone can relate to:
People naturally estimate the amount of time they think it will take to perform a task. When we try to disconnect effort from time, we create an artificial construct that many people, especially analytical people, struggle with. To deal with the problems created by pretending story points aren’t an estimation of time, we must have estimating work-arounds, such as playing poker, t-shirt sizing, voting, voting by ticket, etc.
Try the “that will take me” technique and see how much faster your team comes to agreement on story points. Using this method, it becomes easy to calculate baseline velocity for your team before the first sprint begins. Given everything we do that isn’t directly working on the stories, i.e., meetings, email, ad-hoc discussions, etc., a team member dedicated 100% to the project should have a capacity of roughly 8-13 story points per week and 16-21 per two-week sprint. Start with somewhere around 18 points per team member.
The reason we estimate in the first place is to determine what features we can deliver in each sprint, so the most important characteristic of any system is accuracy. Compare this method to traditional sizing methods and see if your team isn’t meeting its commitments more often.
Pretending story points aren’t about time is a direct contradiction to the Agile Manifesto’s principle of Individuals and interactions over processes and tools.
Comentários