In the following I’ll describe a way of adopting story points and also how to put them into a context that have been tried in “real life”.

The framework is very generic and should be adoptable in other contexts than the ones that I’ve tried. It handles the full cycle from “customers request feature X” to “customer receives feature X”.

I’ve used the following concepts:

• Responsibilities: Grooming/Refinement, Sprinting
• Phases: Scoping of new stuff, Plan, Pre-sprint, Sprint, Done
• Ceremonies: Screening, P.O. Prioritisation, Sprint Planning, Demo and Retro

You can find it all in the illustration in the top of this text. In the next section, I’ll describe each concept.

Grooming/Refinement

Grooming/refinement is the task of taking a user request and breaking it down into something that can be handed over to the developers prior to sprint planning. The primary responsible is the Product Owner (or Product Owner Team).

Sprinting

Sprinting is the task of taking the output of grooming/refinment and turning it into features that the customer receives at the end of the sprint. The primary responsible is the team and scrum master.

Scoping of new stuff

Every time a customer request is received it is added to a product backlog. This backlog serves as an archive of requests. The request is recorded with an initial size guess (perhaps in t-shirt sizes S,M,L,XL or cost range) and other detailes needed for planning and prioritization.

Plan

Periodically the product backlog is prioritized and a tentative release plan is maintained. The items on the product backlog are broken down into smaller pieces that can be built within one sprint. This is done in cooperation between the Product Owner and the team members. In order to break down the items it’s important to capture the ready criterias (what is needed to start this item) and done criterias (how do we assert that the item is completed) for the item. Once the break down has occured the team nominates each new entry with a relative size (such as story points). Please note that it’s important to sequence the work by prioritization/rank and pay close attention to the release plan; don’t break down items that are scheduled for distants sprints – focus on the near future!

Pre-sprint

Before each sprint planning session, the Product Owner sets a scope for the coming sprint. This is done by looking at the historical through put of the team. He then generates a vision statement (or pitch if you will) that can be communicated on the sprint planning session.

Sprint

The team works on the items that has been chosen for the current sprint at the sprint planning session. During the sprint planning session the team breaks down items from the product backlog and adds it to the sprint backlog until capacity is sufficiently covered (consider load factor and capacity of the team). Scrum Master is responsible for following up on estimates and removing/identifing issues and impediments on the way.

Done

After the sprint is over and the Product Owner has approved all completed (done) items the Scrum Master reflects on the gathered data in cooperation with the team at the retrospective meeting. The data to be reflected are story point throughput, detailed estimates vs. actual time consumption, etc.

Screening

The Product Owner is responsible for screening the incoming requests: Are the requests relevant for the product and is the business willing to pay “the price” for the request?

P.O. Prioritization

The Product Owner is responsible for prioritising and ranking the product backlog and aligning this with the release plan. The team should only be presented with one single list of prioritised/ranked items. It’s the job of the Product Owner to aggregate this list from external prioritisation.

Sprint Planning

The team calculates the capacity for the coming sprint and define a load factor. From this a range of items are broken down until the capacity of the team is covered sufficiently.

Demo

After sprint completition all finished (done) items are presented and approved by the Product Owner. It’s important to only demonstrate items that are 100 % done.

Retrospective meeting

For each sprint the team conducts a sprint retrospective meeting with a focus on continous improvement. Both in terms of the internal process in the team but also other factors may prove important. Remember to note down action points and assign responsible persons for implementing the change!