Over at my job, we’re just two weeks away from our first release! I thought this would be a great time to look back a little at our tools and process.
Process
From the day I joined, we’ve been developing via a scrum process. For those not familiar, the highlights are:
- Everything you want to do goes onto a prioritized list called the backlog.
- Write requirements in the form of user stories. (As a <USER> I can <FUNCTION> so that <REASON>)
- Anyone can add, only product owner can prioritize.
- Team agrees on what backlog items they are going to work on during a planning meeting.
- Create todo list from user stories.
- Track progress through iteration.
- Repeat!
We started out with 4 week iterations, with some serious pros and cons. This gave us plenty of time to get large features in, but we were also finding that EVERYTHING was getting checked in on the last day. Despite the claims to mimize dependencies, I’ve found that there are ALWAYS going to be some there. We didn’t do a great job identifying and planning for these, so often we had a huge crush at the end as everything was unblocked. Everyone was busy the entire time, but we were losing sight of the iteration goal and occasionally coding to the todo list, vs the actual goal of the user story.
As part of our sprint review, we talked about some fixes, and identified a T-2 meeting. Basically, we decided to meet halfway through the iteration, discuss how things are going, and plan out the rest of the iteration. Make sure dependencies are met, etc. These were taking 4 hours, almost as long as the sprint planning meeting. That’s when Steve Ross had the brilliant idea – we’re basically just doing 2 week iterations at that point.
2 week iterations have worked well for us so far. It’s way more focused. Our review and planning sessions are shorter, and easier to handle. Our velocity is still increasing, and no one has started making weird sounds and muttering in a corner… yet.
Tools
Say what you want about pen and paper, but I’m a geek, and love the toys. We use a bunch of tools here:
User stories are input into Jira, either directly or through the Greenhopper plugin. Once a week, I go through and prioritize the user stories in the backlog with the great drag-and-drop interface Greenhopper provides. As needed, we have planning sessions in which we break up large user stories into smaller ones, and play planning poker to assign story points. We use paper cards for planning poker still. :) Results are all put into greenhopper.
As we go out and talk to customers, we create a confluence wiki page for each customer visit. We then go through the notes, and link to relevant user stories with a simple user macro (GALAXY-562@jira) that expands out to the full URL of jira. Trackbacks are turned on, so when an engineer wants to know more about a user story, they can find the notes easily directly linked from the Jira issue.
We do NOT bother creating a Confluence page for each iteration. Haven’t seen the need so far.
As part of our planning process, each user story is decomposed into it’s tasks. During planning, we walk around with big post-it paper in a conference room, writing down all the tasks, then marking the hours and time each of us is going to spend. At the end of the planning, one person then types it all into Jira/Greenhopper. Yes, this is tedious, but it only takes ~1 hour. We’ve tried having people type their own items in, distributing the problem, but nothing shows up. We’ve tried skipping the paper, but for brainstorming, nothing beats paper.
As we start development, users drag-and-drop their tasks in the task board view of Greenhopper. Once a day, they indicate how much time they’ve spent and how much remaining. Usually takes <5 min per day. For each user story, we create a branch in subversion. All development is done in the branch, until the user story is complete. This does sometimes cause some trunk merging issues, but it’s not that bad, and the benefit of keeping this all separate is well worth it!.
Our product is UI driven. When we need to figure out what to display to the user, we use this AWESOME Confluence plugin called Balsamiq. It’s plain and simple the best way to do mockups that I’ve seen yet. All done through a web browser, you drag and drop super quick. It’s perfect for conveying the thought, without getting bogged down in the stupid details that don’t matter anyway.
Our build is a little strange. We’re creating an appliance, made up of postgres SQL, python and ruby code. Technically, there’s nothing to build, just pull together. We created a customer shell script that pulls all this stuff together into a nice tar.gz file automatically. We have bamboo call this script once a night for trunk, and poll the subversion server every 10 min for each user story. The build script has a test-harness call out available, for long and short testing. Our trunk builds get the long testing, user stories the short. The short test just does a quick selenium test to make sure that everything loads as expected, and there is no crasher bugs. The long test actually goes through and exercises all the UI components, timing how long everything takes. All testing outputs junit XML, which bamboo then slurps up automatically.
At the end of the iteration, we delete the user story build plans from bamboo, label the build we’re keeping, and create a branch for our iteration release, just in case.
Overall, this set of tools has been fantastic. We’ve spent right around $5,000 for all the software. That’s a significant chunk for a small company like us, especially when there are such great free tools all around, and I’d spend it again in a heartbeat. The quality of these products is just outstanding. The support is great from everyone, and Atlassian in particular needs to called out. I’ve had 4 issues worth submitting as tickets, 3 of which they handled in < 2 hours, and 1 was my fault.
