Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Does anyone know how I can train a bunch of engineers about user story points in 30 mins.
I wanted to make it fun and interactive but I only have 30 mins.
My initial idea was to simply go over the core concepts of relative, complexity, uncertainty but I thought maybe there is a good analogy I could use.
I would write a short presentation about what Story Points are and how they are used (a summary of this explanation should work nicely; the dogs example is really intuitive).
I would also mention some pitfalls or common mistakes just to get some of them out of the way, since people will have a few questions. Trying to provide some answers to common questions or misunderstandings upfront will save you some time (a summary of this, from the same author should work).
Try to go through this in max 10 min. Rehearse if you have to. Change things from the presentation, remove things, etc, until you think you can get the message across while keeping within the time limit.
Then use the rest of the time to actually have people estimate a few things, together with the discussion to reach consensus (you choose the example; maybe something from the field the engineers work in).
You are really short on time so this might work or not, but either way, you might leave your contact details (if possible/permitted) for them to ask questions later, if someone wants more details. Or leave them with some reference material at the end, like the two posts above, to learn more.
How I do it:
I set up a grid. Across the top I have a size scale. I actually don't use numbers at first. Rather, I use ice cream: taster cup, single scoop, double scoop, sundae, banana split, bucket. I'll come back to why later.
On the left side, I have a list of things. Usually I use household chores and tasks, but you could even use real backlog items. I ask them to pick one that's in the middle for size. If they need prodding, I ask them to average up complexity, effort, unknowns, etc. I put that one under double scoop. Then we go down the list 1-by-1 and ask "is this a bit smaller, a lot smaller, a bit bigger, a lot bigger?" until they are all mapped. Along the way, there will be opportunities to show how complexity, raw effort, and unknowns play into the sizing.
In the end, I write 1, 3, 5, 8, 13, 21 on the ice cream scale and talk about how the numeric scale shouldn't be over-mathed. A single scoop and a double scoop don't give you a sundae. And you would sound dumb to say "ok, it's 4 hours for each scoop, the fudge is worth 2 hours, and a banana adds 4 hours". Don't do these things with the numbers either.
As a final point, Mike Cohn has a wonderful blog on the relationship between points and time - how it's related, but not linked. I often share this with people to read later. https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points
Planning poker is the secure, fun way for agile teams to guide sprint planning and build accurate consensus estimates choose, it is a fun way to estimate story points. You can download the planning poker cards app. The game is usually organized by the scrum master, each member of the development team chooses a number depending on their estimated effort required to build or test a feature. They are required to defend their position attributed to the feature build by giving reasons. The most tenable choice is attributed as a story point.
