SCRUM & Planning1 – determine the WHAT

SCRUM Planning1: Well prepared Chaos – The WHAT.

Goal of SCRUM Planning1 is to explain the team WHAT should be accomplished during the course of this sprint.

In theory, the product owner has a well structured backlog (actually usually a spreadsheet πŸ™‚ ) where you find user stories, estimated, already well thought-through, prioritized according to their business value and hence is very well prepared to guide the team through the SCRUM step 1 in the sprint – Planning1.

Well, after 2 years of SCRUM, we are close to there – close to – not yet there.

Initially, we had heavy struggles to get the company wide backlog setup at all. We had lots of stories in there ranging from small stories (1 to 13 story points) up to giant stories (estimated with 100 to ?) – but still in the backlog. We had stories in there with clear business value and others claimed to be “strategic”. We also had stories in there which weren’t good user stories at all (“Fixing the XYZ issue on technical element ABC”). So, we had all ingredients for a really bad Planning1 – and we had several of them. Some of them went to a point where people left the room – entirely agitated. The early days.

Now, we have product owners being on top of their backlogs and user stories. Stories being estimated higher than 13 need to be broken down into smaller pieces. Why? Experience shows that stories estimated bigger than 13 are too complex to be estimated reliably. All stories need to be estimated. Why? The team needs to know what to be expected in the Planning1 session and the product owner is forced to think-through the whole story. One point which is still tricky is the actual metric to measure business value. For the time being it’s still a mixture of our VP Product discussing with the product owners – but at least it’s an identified way to prioritize the backlog.

Lessons Learned?

  • The product owner needs to be on top of his backlog (be it the company backlog or the team backlog).
  • Stories need to be small enough to be understood fast and easy.
  • The team needs to be involved as early as possible (pre-estimation ideally).
  • You need a properly filled backlog and ideally you find a metric to measure business value in an objective way.

SCRUM Sprints – The mechanics.

SCRUM Sprints: One Sprint in a Live.

The typical structure of SCRUM – the mechanics as I call them – are quite common. No big adaptations in the industry. I still want to go into the various elements to highlight the tiny little details we decided to change and where and why.
SCRUM Sprint CycleThe graphic actually shows the structure of our SCRUM mechanics.We have all typical elements: Planning1, Planning2, daily sprint stand-ups, estimations, review and retrospective. Since we’re developing software and came from a project / waterfallish work-model in the past we still have some actions for final release testing and the actual software release.

I talk about the various elements in seperate posts in greater detail:

Lessons Learned?

  • The mechanics of SCRUM reflect the fundament of a potentially successful working model. You just need to get the details right πŸ™‚