How to do SCRUM with Basecamp?
About 2 years ago we were sitting at the office trying to figure out which tool to use for project management. I mean, being agile is about being simple, but index cards were starting to get messy. Bad handwriting was starting to make things unclear (Is that an "r" or an "f"?). Finally the decision to look for a tool was taken when one of our project managers dropped a cup of coffee over a deck of story cards.
There were many tools out there that could help us out, and perhaps we tried several of those. There was the good old FogBugz, which seemed more focused on taking track of problems rather than help us organize the project. We also considered another tool that I can't remember it's name, which allowed us to define workflows. The customization was so hard (and it required us to install some weird active X control), that we decided to skip it. And finally we had all these "agile" tools that require some sort of "certification" given by some consulting firm. I don't know about you, but certifications don't sound really agile to me.
Of all the tools we tried, the one that gave us the best results was Basecamp. These are the two reasons that we believe make Basecamp great for agile project management:
- Simplicity: There is no need for training when you start using Basecamp. In essence Basecamp is a set of message boards, blogging tools, calendars and to-do list trackers. All these tools combined in an intuitive way is what Basecamp is all about. If your team can't figure out how to use Basecamp... you're in troubles. Being agile is about using the simplest tools available.
- Interactions instead of Process: The purpose of Basecamp is to promote and enhance collaboration between a team. Basecamp doesn't try to force you into a specific workflow as most project management tools do. You can pretty much do whatever process or workflow you want, and still, Basecamp is going to be helpful. Guess what's the first line of the Agile Manifesto? Individuals and interactions over processes and tools. So instead of thinking "Is ticket 4137 assigned to David or to Paula?", you will see the discussion of a real issue between your team.
But since Basecamp has no process or workflow embedded on it, how can we adapt it to an agile methodology? Before explaining how we did it, let me talk a little bit about the software development method that we used at your office. In our office we used a mixture of Scrum and XP. We basically had our product backlog based on a set of user stories. We tried to measure our team's velocity and based on that to estimate how many iterations we would require to finish a project. We used a sprint burndown graph that we updated daily to keep track of how we were doing with respect to our plan. If we ever saw that we were not going to be able to finish all the work we thought we could, then we talked with our customers and explained the reasons.
Ok Ok, Now Here is How
Our process was more or less the following:
- Make a mind map to identify the project vision, goals, risks and stake holder. You know what a mind map is right? Something really important, make sure to have this step right. Consult with your customer and make sure that you share the same vision. How we used Basecamp here? By keeping track of the communication with the customer. Once you have your vision written, you can set it up as a Basecamp Announcement, so that it can be shown to all the project member every time they log on.
- Have one or more Story Writing Workshops. Here is when the user comes with his big christmas list that includes all his unicorns and care bears. Everything the user wants must be taken into consideration but you need to make sure that the user is able to formulate his dreams with the following format: As a "role" I want to be able to "user wish" so that "business value". If the user is not able to fill out all the blanks then it means that either you can't identify anyone that is going to make the task, or the task has no value for the business. I find that using Basecamp writeboards is really good for managing your stories (And even better if you have a Backpack account, you can create a note for each user story, and move them like a stack of cards between different Backpack pages). Index cards can be used as a fast way of writing the stories, but if you need to share them with a lot of people, it's better to have them online.
- Estimate Story Points. You need to decide how hard each story is in comparison to another. We used to have a limited set of possible values for this task. The possible values were: 1 - 2 - 3 - 5 - 8 - 13. No other value is allowed, if you need something smaller, then you need to join the story, if you need something bigger, then you need to split it. Again, if you need to do this in a distributed environment, Basecamp can be very helpful to keep track of the discussions.
- Plan Your Iterations. Make sure that the customer understands that the date you will be giving is only an estimate. Be careful of setting expectations that you won't be able to accomplish. Usually at this point your customer would want to cut out things that have very low business value (probably the unicorns and care bears will have to wait again). Once you have a deliver date for each iteration, create a milestone for each iteration in Basecamp.
- Define the Tasks for the First Iteration. Take all the stories that are going to be developed in the first iteration and think of all the tasks that are going to be required for each one. Remember to consider the tests, the coding and the research. Finally until you get to this point you are able to start talking about how many hours a task might take you. In Basecamp you are going to create a to-do list for each user story. Each of the tasks is going to be a to-do item in your to-do list. Make sure to assign each to-do list to the milestone that represents the iteration in which it's supposed to be delivered. If you figure out at the end of this step that you have space for more work (usually it never happens) or that you're scheduling more work than you're able to finish in one iteration, move user stories (and I mean the complete story not only a few tasks) between iterations. Remember to talk to your customer about any changes you're making on the expected delivery date of each user story.
So that's what you do to plan a project in Basecamp using a mixture of Scrum/XP on it. We've only discussed about the planning of the first iteration. The next step is:
Keeping Track Of Your Project
At this point your job is to keep track how your team is advancing through the to-do items you created previously. As usual you will discover new tasks that you didn't think before hand. If this happens make sure to add them to the to-do list that represents their story. The ability to post comments on the to-do items works great when you need to record any discussion or insights your team has about a task.
One thing I forgot to mention previously is that when we create a to-do item, we assign an estimated amount of time. Since there's no way to add time estimates for each task we simply add the duration estimate as a string at the end of the task. For example a task would say something like:
Refactor Rick's messy authentication class. 2h
One thing that is important to do is to remember to re estimate the tasks daily. That will keep your expected time to remain realistic. Usually there are two or three tasks that take less then expected, but there's always one that can take 10 times longer.
Some people like to use the time tracking features of Basecamp to keep track of their tasks. Although time tracking works fine for tracking how long a task took, it doesn't tell you what your customers would probably be more interested on: how long will it take you to finish? For this reason we think that the labels on the to-do items are by far more important then the time tracking capabilities that Basecamp offer (this is because of our business model, we charge a rate based on the amount of iterations that the project will take to finish, we don't count the exact amount of hours we take on each task in order to charge).
We usually don't assign the tasks to anyone until we do our daily stand-up meeting. During the meeting each developer picks up a story (or set of tasks) they would like to work on and by assigning the tasks to themselves, they commit to complete the work.
That's it!
Once you're about to finish an iteration, you can print your milestones, and message boards. You will get a professional looking document that will tell you what happened during the iteration (works great to impress your customers during iteration reviews). Once done with an iteration, do the same thing for the following ones.
We're Missing Just 1 Little Thing...
The only thing that Basecamp doesn't offer is the ability to generate a sprint burndown chart. For that purpose, we used to keep a copy of the task list on a spread sheet. From the spread sheet we can then generate the burndown chart. Keeping the list in the spread sheet and in Basecamp at the same time was a real pain in the rear, and for that reason we built a tool that uses Basecamp's API to generate the burndown charts for us.
We liked the tool so much that I figured out that we should actually start selling it. In a few weeks we're going to be done with the subscription management process. Here's a link to it if you want to learn more: http://www.burndowngraph.com
16 comments
Jun 25, 2009
Rafa said...
Nice. Just what I was planning to do (but mixing Scrum with RUP). Quick question, how do you move stories between iterations? A story is defined as a todo list. I know you could move tasks between todo lists. But where do you move the todo list?
Jun 25, 2009
High Notes said...
If you want to move a story to another iteration, just change the milestone to which the to-do list is related.
Jun 26, 2009
High Notes said...
Hello Ryan, since to-do items in basecamp don't have an "estimate" column, what I do is simply add the time estimate to the task as part of the to-do item label. So if I have a task that I think that will last 2 hours I would name it:* Task Name 2h
If after working for an afternoon on it I realize that it will take me longer than expected and that I need to work on it for 3 more hours I would rename the task like this:
* Task Name 3h
I would also place a comment on the task explaining what went wrong on the original estimate.
Jun 26, 2009
High Notes said...
@Ryan:About your second question, I guess that what I would do is to create a project for each team. Basecamp's dashboard can be used to check out the state of multiple projects (although I think that you can see up to seven projects there).
Jun 26, 2009
Ryan said...
tricky thing then becomes burndown management and assessing where your team prI really wish Basecamp had more of an Agile mode to it, just a few simple features, not hacks Our teams use Hansoft, which has excellent Agile features. Problem is that it does not have the collaboration and visbility features in Basecamp.
Jun 26, 2009
Ryan said...
How does your time show "work remaining" on a backlog item? Also how do you manage capacity planning. I can see Milestones working great for "releases" but what about sprints?Thanks :)
Jun 26, 2009
Ryan said...
also curious how basecamp would work for much larger development projects, i.e. 20+ Scrum Teams?
Jun 26, 2009
Rafa said...
Thanks for the reply :) will try soon
Jul 06, 2009
Blair Rorani said...
I use pretty much this same method. One tweak I use to help clients that don't quite understand iterations etc is to create a milestone for each user story and link it to a to-do list with tasks/tests for the story. Instead of an iteration you can simply see several milestones with the same due date. Basically all stories in the iteration without calling them an iteration.
Jul 06, 2009
Blair Rorani said...
@rafa a milestone can be a sprint or a release. A sprint is simply a set of milestones with the same due date all linked to their to-do lists with story tasks/tests. A release is just another milestone. All previous milestones (sprints) are part of the release.
Aug 26, 2009
Grayson Koonce said...
Great post. One challenge our team has encountered is the use of computers during the daily scrum (stand-up). Pulling up the computer every morning and manually updating the Sprint Backlog puts strain on the lightness & quickness of the scrum, we've found that simply standing up around a board of story-tasks fast-tracks the process and allows us to stay within the alotted 15 minutes. The Scrum Master prints out the Scrum Backlog and notes updated estimates as each member takes his turn during the stand up, then he updates the backlog afterwards.
Is there a way to use utilize this process without weighing down the stand-ups with the need for a computer?
Aug 27, 2009
High Notes said...
Using a computer for a standup meeting is not a good idea. What we did was have the meeting in front of a whiteboard, write important stuff there and simply take a picture of it with cell phone. Upload the picture if you want to keep record of the meetings.If a point of the meeting is important enough, you can start a discussion in the messaging section.
Nov 04, 2009
Andre said...
Great information, we also use Basecamp on the same way, but we are now facing another step: how and what tool to use that will let us see all our projects and decide which one is going to be delayed or need more resources? We work on many projects at the same time and at this point we cannot see all of them together to determine what to do in case of delays. Any tip or help would be appreciated.
Nov 04, 2009
High Notes said...
You can use burndown for that. Create a burndown chart for each of your projects, and keep track of how the iterations develop. In that way you will be able to see which projects will not be able to deliver all the stories planned for their current iteration.
Nov 04, 2009
Andre said...
Thanks, but we will be able to see all our projects side by side?
Nov 05, 2009
High Notes said...
Not exactly side by side, more like scrolling down a list.
