Diving into Scrum - Intro to Scrum Methodology

A large part of what I do every day involves working with software development teams that are generally new to Scrum and one of the tendencies I've observed is that Project Managers who are converting to a Scrum Master role lean towards over-complicating the whole thing before they even start.

Here's what I mean:

Imagine that you're not only new to Scrum, but new to Agile altogether and you've just received the directive that everything you've been doing up until now is wrong and we're adopting this new methodology wholesale in about 2 weeks.

You'd probably do what I did when I first got thrown into the deep end, you'd buy a few books, search the internet, maybe read through a few Scrum forums. The problem here being that you might come back with this idea that Scrum is extremely complicated and therefore difficult to implement. After all, you have to figure out what a user story is, understand story points, come up with a scheme for creating estimates, figure out all the intricacies in extreme programming, etc. etc. etc.

Let's step back for a moment and figure out the core pieces and then we can add in the complexity as we need it.

So what needs to be here?

• Well we're gonna need a sprint which is a short timebox, we do work within the duration of the sprint. For this to work correctly, we need two meetings for each sprint. One for Sprint Planning and one for the a Retrospective on the Sprint.
• We'll also need work to do, this will be the product backlog which is a list of things we can accomplish in a sprint.
• Someone needs to figure out which work from the product backlog gets done first, that will be our product owner who represents our customers.
• We also need to figure out how much work from the product backlog can go into a sprint so the backlog will need to be estimated at an item level.
• Somebody needs to do the work and create the estimates so we'll need a development team. Just to keep things properly branded we'll name this the Scrum team.
• Lastly we need someone who knows all the Scrum stuff. Branding is still important so we'll call him the Scrum Master.
• We need communication. We need the developers talking to each other so we'll set aside time for a very short conversation each day for the developers to touch base with each other. This usually involves the team standing up for a few minutes to discuss the day so we'll call it the Daily Standup.
• We also want to keep things transparent so everyone knows how the sprint is going. We'll allow anyone to listen in on the aforementioned daily conversation and also see the total work remaining per day in a chart. Since this chart burns down to zero work remaining over a time scale we'll call it a burndown chart.

So to break it down even further, we need:

• 3 roles: The Product Owner, The Scrum Team and the Scrum Master
• 3 meetings: Sprint planning, the Daily Standup and and the Sprint Retrospective
• 3 Artifacts: The Product backlog, the Sprint backlog and the burndown chart.

There's still some small bits and pieces missing but we've covered the base needs. Do all of these things and you're already doing Scrum, the rest will be filled in as you need it.