Dave Bouwman and I had lunch with some friends from another GIS company yesterday. They wanted to talk to us about our experiences with agile and Scrum. They're very interested in implementing Scrum as their "methodology" of choice for their development teams. But, they kept alluding to the fact that they needed to come up with an "official" date to get started. The conversation continued and I finally asked my burning question "So, what's holding you guys back from getting started?"
The answer was that they needed more time to get their backlog together and have it be adequately defined. I thought about that for a while and made a few suggestions that I think any teams can use to quickly get started using Scrum. First and foremost, I think teams shouldn't worry about making their Scrum start "official" or sanctioned or even extremely well defined. Many very successful Scrum teams started completely under the radar by implementing some simple elements of Scrum that made them more effective and efficient. I also think teams shouldn't worry about getting it "right" the first time. Remember the Scrum mantra "Inspect and Adapt"? If you start off and don't get it right, inspect, adapt, and keep moving forward.
OK, so what to do about your first backlog, right? If you really want to get started quickly, assemble enough of a backlog for maybe 2 sprints. Get your Team started on those backlog items, while the ScrumMaster and Product Owner hash out the details for a more comprehensive backlog. If you'd like to do more planning and feel better about your backlog, build a backlog for a single release. Let your Team get started on that backlog while again, the ScrumMaster and Product Owner build out more release backlog items for future releases. Finally, if you really want to assemble a detailed backlog before your Team starts working, consider a Sprint Zero. Make Sprint Zero a one-week Sprint where the ScrumMaster, the Product Owner, and the Team work on assembling a detailed backlog. You can also use Sprint Zero to put anything else in place that you think you need to support your Scrum implementation.
When you're assembling your first backlogs, keep in mind that you don't need to put excruciating amounts of detail into your user stories that are farther down the line. The level of detail in your user stories should be proportionate to how close you are to actually working on the story in question. The further in the future the user story is the less detail it should contain. Remember that one of the benefits of Scrum is the reduction of time wasted on requirements that may not ever be implemented. It is more likely that a user story that is one year out will not be implemented than one that is just two weeks away.
So, what are you waiting for? Pick a project, big or small, get some quick backlogs together, and start scrumming today. It's never too soon.
Posted in Agile Estimating & Planning | Scrum Fundamentals | Sprints |Comments [1]
The content of this site are my own personal opinions and do not represent my employer's view in anyway.
All content on this site © Copyright 2008 Chris Spagnuolo GeoScrum! by Chris Spagnuolo is licensed under a Creative Commons Attribution 3.0 United States License.
Sign In