So you're ready to kick off your first Scrum project and you ask the inevitable question - Where do I begin?
You start in the same place innumerable product teams have started before. You gather requirements. Lots of organizations gather all the requirements at once, building a pristine Product Requirements Document (PRD) that Can Never Change. Scrum doesn't do this. Instead, you can look at a requirements gathering as a good place to start, but it's not where you're going to finish.
The first thing you'll do is sit down with all of your well-defined Scrum roles: The Product Owner who is or is representing the customer. The Scrum Master who will be guiding the project and shielding the team from the PO. And the Scrum team itself - the developers and validators. We call this the Product Planning meeting. The expectation is that the PO is primarily responsible for the content of the meeting. Either they've come with a list of requirements or are handing you a traditional PRD. Each requirement gets discussed, prioritized, and a rough estimate on how long it will take to complete is attached.
In Scrum lingo, this turns out to mean we:
-
Create stories - Stories are individual requirements with well-defined acceptance criteria. In other words, how can we demonstrate to the customer that we've met the requirement? I also prefer tools that can strongly associate stories with the individual tasks needed to complete them.
-
Prioritize stories - We set an initial order of execution, subjective value, or Return on Investment calculation on the individual story.
-
Assign story points - We set a subjective "story size" on how long the work will take. For my team this is a completely fictional number that evolved over time. We tried to size stories by day: A five point story would take a work week to complete. But somehow, given the people on the team, that turned into eight story points per week. So these days we know we can finish sixteen story points in two weeks of time with the people we currently have.
If you're moving from Waterfall to Scrum and have a PRD with a hundred items in it, your Project Planning meeting will take a long time. You'll probably have to break it out over a period of days. In my experience translating a traditional PRD into Scrum is really interesting: You learn that most of the High priority items get done, but not so many of the Mediums and hardly any of the Lows. It's another indication that static requirements up front don't work.
After your Project Planning is complete you'll have two things: A well-defined backlog and a team that understands all requirements for what they're coding. I strive for common ownership on my teams, so the latter is really important. The well-defined backlog lets you estimate how much time the project will take. I've found that my initial estimates are pretty close to the real thing for projects under three months in duration. Often I'll just say, "Okay, the project ends on [DATE], and we commit to completing all High priority items." From there we can negotiate with the PO if there were Mediums that really should have been Highs, and vice-versa. It's a liberating feeling to air all of that in the very first meeting: Clear requirements, realistic expectations, and a knowledgeable team.
What you're avoiding...
My last note is this: With lower priority projects, say for internal software, we've had a hard time getting a committed Product Owner. Ask yourself - If my project doesn't have a single, dedicated owner, is it really worth doing? I won't vent about invisible POs except to say that I think this is the most important role in Scrum. You can't live without it.
Tasks accomplished: Roles defined, Backlog defined
Next up: Starting the Sprint
Technorati tags: Scrum Scrum Process