Doing Scrum with CodePlex
I thought I would share a little insight into my brain on planning releases for my SharePoint Forums Web Part using the Scrum development process and what CodePlex has to offer to support this approach.
As you know, CodePlex is a community site that hosts the forums project and there are a few nice tools they’ve baked into the system that help me plan my work a little better. Even though I’m a one-man team (although I’m just ramping up to expand this) I still follow Scrum to plan out the releases and manage the work. Here’s how it breaks down.
The entire Issue Tracker is my Product Backlog. I export all unassigned items to a CSV file via CodePlex online. Then I apply a filter to be able to sort and view the data. Each Sprint is 1 month, delivering on (or about) the 1st of the month. Before I export the work items, I add the next sprint release date and version so it’s available in the filtered data (I have to assign something so it shows up in the filtered data list but I just move this item back to unassigned when I load up the spreadsheet to work.
Two more things I do is assign new columns to the spreadsheet after the export. First is my story points column. Rather than working on hours for estimating, I use points. Each item gets either 1, 2, 3, 5, or 8 points assigned to it. Nothing is larger than 8 points (meaning it’s going to be a lot of work). More on the point system later. Second is a priority column. CodePlex provides High, Medium, Low for priority but for Scrum you have to use numbers. There can be only 1 number one priority (even if multiple people are working on the system). After all, if everything is High how do you know what one you do first?
Then I’ll do a couple of sorts and filters. First I sort out the features from the issues (bugs) from the tasks. Tasks are just things that have to get done, and depending on whether or not they have enough priority they’ll get included in the next release. It’s give and take whether I include a feature or a bug or a task in the next release, although I’ll try to include bug fixes before features and features before tasks (at least I try to plan it that way). Once I’ve gone back and forth with each item, I’ll give it a priority. The decision on what goes before what is driven by the community (that’s you) and my own judgement of what’s important. Bugs that are really stopping people from using the system easily get higher priority than new features that nobody wants. On the flipside, features that people really really want will take priority over low priority bugs that people rarely stumble over or care about. They’ll all get done, but as I only have a finite time, I try to position things higher up the priority scale to get the best bang for my buck.
So now I’ve got a modified backlog with a list of items sorted by priority and a column showing how many story points it will take for each item. There are tasks that will be added later, but for now each story has it’s own weight based on things like how complex it is, if there’s already existing infrastructure in SharePoint to leverage, is this something I’ve done before, can I find an example on the web as to how to do this. Stuff like that. Now it’s time to figure out how many things I can fit into the iteration. I’ve time boxed the iteration at 1 month however contrary to popular belief, I don’t work full-time on this so it’s really more like a couple of hours every few nights. At my current velocity I can finish off 15 points per iteration. How did I arrive at this number? Based on the two releases I have, that’s how many points I finished previously. So for me, 15 points is a months worth of work doing a few hours here and there.
Now its time to go through the list and see what fits. If I can cleanly find 15 points from say the first 4–6 items, I just call it a day and that’s the release. If I can’t, then I need to shift some priorities around. Sometimes a #5 item gets shifted down to #7 because it’s too big to fit into the rest of the available points and item #6 will. It’s just numbers and works out well. Once this is done, I assign the items to that release number on the CodePlex site and export those items to a new worksheet which becomes my Sprint Backlog for the next release (I only priortize and estimate one release ahead).
They’ll be adjustments. With each release I look over how many points I completed and see if my velocity is improving (or not). This has an effect of auto-correcting my estimates. If I keep going at my current estimate of 15 points per iteration, I’m fine but if I find that I only deliver 10 by the time the end of the month comes I know that I under-estimated on 5 points. I’ll take a look at where that way (perhaps it was a feature I thought I knew what was required to make happen, but got bogged down by details). Cosequently, as I might bring on more people the number of points we achieve could go up but it doesn’t change how simple or complex something is. In any case, I’ll correct the project velocity as things change and hopefully estimating will get a little better on the next release.
Yeah, it’s a lot of work for a one-man project that comes out every month and there’s the danger of me running too many projects at this speed. However it gives me a good feeling that I know what the month of work is going to look like, I can pretty confidently estimate how many features are going to be delivered with the next release, and I can talk to people during the month about what’s coming which should hopefully help me plan the next release after that.
It’s not pure Scrum either as in 1 Sprint = 1 Release = 1 Month, but it works for me.