Posts Tagged Planning poker

Getting them through: user stories at sprint planning and “estimates temperature”

“If you can not measure it, you can not improve it.” Lord Kelvin

I’d like to continue with “Getting them…” topic (see previous post “Getting them READY: user story life cycle and “Epic Box” principle“). Today we’ll be getting them (stories) through Sprint Planning Meeting (SPM)…

Assuming all stories are INVEST and backlog is prioritized according to value, return-on-investment, risk, etc..

Then it comes to sprint Planning Meeting (SPM) itself…

Here are steps that will help you to get stories through:

1. Be prepared

As Product Owner (PO) you should be quick with decisions as some estimates may be quite “surprising”. I recommend have “plan B” on every story in mind (see Negotiable from INVEST of previous post) as pre-decision what acceptance criteria (AC) it is possible to live without or separate and your idea of estimation prepared.

2. Present it. Sell it!

Start with presenting the goal of the sprint, follow up with  idea behind the story and the problem it solves. Do it in the way to get team buy in. Of course it is your responsibility to decide what is important and what is not, but knowing WHY this is important is vital for correct story implementation and has positive effect on team’s feeling of urgency. Be ready for questions and address them with patience.

3. Applicably question

You should be ready to question estimates if they go beyond your expectation. This is important as empowers “constructive conflict” between parties (team and PO). But please keep in mind that you should be very careful doing this as it should not look like putting a pressure on team.

For instance, instead of asking “Why this is 13 (20, 40, …) story points?” that implies hidden context and will most likely lead to a defensive and broad technical answer you will not benefit from, ask “What makes it 13 for you?” or “How I could split this story so it takes less?” or “What AC make it like that?”, etc.., which is more direct question and assumes no hidden context. Most likely you will be provided with non-technical answer and will be able to judge on “expensive” functionality.

3. “Decode” estimates and implement PO Kaizen 

Estimation process is valuable feedback to PO on stories quality and granularity and it makes sense to use it right. Why? Because as PO you will learn  to improve your  stories and size them the way it will lead to fast, stress-free sprint planning meeting as prerequisite for  successful sprint.

How to “decode” team estimates

Here is my hint: as you know user story point is relative measure of work, but to me estimates have also different meaning  that “signals”, I suggest to be interpreted by PO as follows (assuming that same team estimates continuously using same baseline):

  • 0 USP (orange) – you may have no idea about your product, this functionality is in place;
  • 1/2, 1 USP (yellow) – small (usually cosmetic) improvement. It is OK to group several such improvements in a single story if they contribute to the same WHY clause of story description;
  • 2-3 USP  (light green and green)– small to medium size functionality. All is well 🙂
  • 5 USP (green) – medium size functionality. All is well 🙂
  • 8 USP (dark green) – big size functionality, any way to make it easier or split into smaller? But all is well still:)
  • 13 USP (orange) – do you understand WHY this cannot be smaller/indivisible?
  • 20 USP (dark orange) – you should have very STRONG reason of having such a story. Make it smaller and simplify;
  • 40 USP (red) – no way this will be done during a sprint. Understand what makes it that big and split;
  • 100 USP  (dark red) – damn big amount of work/ambiguous acceptance criteria/big doubts, serious problems, etc;

When turning those signals into color scheme planning poker logically turn into sequence, reflecting “estimate temperature”:

4. Track time

Besides, I recommend to track time spent per user story discussion (use hourglass or timer, or ask your scrum master to facilitate). My observation of sprint planning over 2 years proved that team usually able to estimate ~10 user stories per hour as average (3 teams of ~ 15 people in total). Of course it depends on the size of team and many other factors, but to me if a story takes more than 10 minutes to discuss, PO shall do something with it (question what causes doubts, remove story from planning completely or partially).

5. Ask for feedback

Asking for short feedback at the end of sprint planning also helps to improve. It’s good idea to hand over paper with INVEST acronym reminder where team members place comments on stories and quickly feedback to PO in the last 5 minutes of SPM, referring to particular quality of INVEST and particular story that had not meet this requirement. This is timeboxed to 5 minutes and helps to improve quality of SPMs a lot.

To be continued…

, , , , ,

1 Comment