Normalizing Story Points NEUTRALIZES Story Points – Agile Estimation Problems and Myths, Part 1

Sometimes teams, and now well-accepted frameworks, misuse and misunderstand agile estimation concepts at a deep level, to the extent that all of the potential value of the practices is stripped away. This series will talk about theory, whys, and whats behind some of the concepts and practices, and allow you and your teams to take back the power and value of agile estimation techniques!

Remember, eight Story Points means two days for our team!

- Many an individual Scrum Team

With a team of 5 coders and testers, use a Velocity of 40 points per Sprint.

- A suggestion a currently well-accepted scaled agile framework might make

flat-icon-mountain-sheep-normal-goats-goatBoth of these statements fall victim to multiple misunderstandings regarding Story Points. I’ll call the two scenarios described here “normalizing Story Points,” as that’s a reasonable umbrella term to cover them both. They are slightly different, though, so I’ll also cover some of the differences below.

There are fundamental issues with normalizing Story Points that remove the advantage of, and any possible need to use, Story Points – that is, normalizing Story Points also neutralizes Story Points – it makes them useless.
Continue reading Normalizing Story Points NEUTRALIZES Story Points – Agile Estimation Problems and Myths, Part 1

Scrum is Chess, Part II

518px-ChessSetIn my previous post, I mentioned that I’ve been getting a fair number of questions lately that go like this:

What does Scrum say about [[ something that Scrum does not prescribe anything for ]]??

Questions are always good. I think I’m dealing with some clients who are a bit more self-aware, Continue reading Scrum is Chess, Part II

Scrum is chess, scaling Scrum is…

chess-316658_640I’ve been getting a fair number of questions lately that go like this:

What does Scrum say about [[ something that Scrum does not prescribe anything for ]]??

I love Schwaber’s chess analogy: you either play chess, or you do not. In the same way that chess does not succeed or fail, Scrum does not succeed or fail. Knowing the rules does not make you a Grandmaster or effective Scrum practitioner; strategy, practice, mentorship, etc. *may* make you a Grandmaster or effective Scrum practitioner. You get the idea.

Scaling Scrum is something that is not prescribed by the rules of Scrum**. But I’d like to tie scaling to the chess analogy.
Continue reading Scrum is chess, scaling Scrum is…