Weekly Story Sizing

The standard Scrum framework prescribes a Release Planning ceremony with a recommended time box of four hours to two days.  And this ceremony, when performed properly, works as one of the major columns in the Scrum architecture.

The problem for many teams is that it's hard to keep the attention of a team for two days on a single task -- and it's often difficult to schedule a quarterly two-day meeting.  This varies from team-to-team and company to company.  Some can facilitate the traditional Release Planning time box easily, where others find it much more difficult.  And as a result, unfortunately, many teams drop this very important structural element.

One of the groups I worked with was experiencing that pain, and was heading in the same direction of just dropping the ceremony.  I proposed we keep the ceremony but look for ways to make it work.

Those of you who are familiar with it, know that the great majority of the time spent in Release Planning is spent in Story Sizing.  For a typical team, a two-day Release Planning meeting is comprised of an hour and a half of presentations by the Product Owner with team and stakeholder input -- followed by over fourteen hours of Story Sizing.

My plan was to separate Story Sizing into a separate ceremony, leaving the rest of the Release Planning agenda intact.  This change allowed us to still "do Scrum" with only the timing and frequency of the Story Sizing task altered from the original framework.

Coincidentally, about two months after we successfully separated Story Sizing from Release Planning, I found a couple of blog posts from Scrum Masters who had come up with almost identical answers to the problem.  And about six months later, a Scrum Extension was published that documented the variation as well.

Here's what we do:

The Product Owner, who is also responsible for the Release Planning Ceremony, schedules a weekly Story Sizing meeting that lasts exactly one hour.  For our group, one hour a week was sufficient to keep our Backlog maintained and the relatively short time period helped focus the team on quick, from-the-gut sizing.

During the meeting, the Product Owner presents the highest-priority story in the Backlog that has no size to the team.  There is a brief discussion of the story and any refinements that might need to be made to it to make it sizable.  The team then plays a round of Planning Poker to determine the size of the item.  This process is repeated with the next-highest un-sized items in the Backlog and continues until we run out of stories or run out of time.

This has worked very well for teams I've worked with, and it has some nice advantages in that new stories that need to be brought into an on-going release don't require a special meeting in order to get sized -- they get sized as a result of on-going process and are normally ready before the team schedules them into a sprint.

I would note that teams starting Scrum should not try this first!  Always run the framework in its entirety and get some experience with it before seeking alternatives.

Also, this meeting is not the same as Backlog Grooming.  That is an additional process that is often employed by Scrum teams, but it is not the same as Weekly Story Sizing.