Rusty Divine

Live, Love, Learn, Teach


I recently changed jobs. The upside is that I am really enjoying the team I am working with and the project we’re working on. The downside is that I no longer work with my good friend Adam.

Today, I am happy to say, we have decided to embark on a side project so that we can continue to work together. Of a list of 15 or so ideas, we came back to the one idea we each separately had when we started working together a year ago – a Disc Golf app.


It’s funny that when thinking about a project done on my own time, my first tendency is to disregard any formal process and just git ‘er done. Why waste time on user stories and mockups – I know what I want, right? Do we need iterations, daily stand ups, and burn down charts?

Back at our former employer, we honed our process for gathering requirements and prioritizing them. We called this an Agile Assessment. For a nominal fee – enough to discourage anyone who wasn’t serious, but not enough to actually break even – we would meet with all the stakeholders we could in one 4-hour meeting. First, we’d lay out the agenda and ground rules. We’d then spend about 20 minutes to define a project objective that could be concisely written on our wall board. From there, we discussed some of the obvious users, and then started brainstorming features and recording them in the form of user stories with a title and conditions of acceptance listed for each one. Each of the titles would go onto a yellow sticky note, and the rest of the story would be recorded in a spreadsheet. When we had 20 minutes remaining, we’d ask all the stakeholders to take the sticky notes and order them from gotta-have to would-be-nice. After agreeing on the order, they would draw a line to separate what had to be there to make the most basic solution from the rest – everything above that line was in our Core Feature Set. Adam and I would then spend a fair amount of time researching and designing the solution (30-40 hours) and present the customer with a set of design documents and a fixed-price quote for the solution.

When we won a project, we broke it into two-week iterations and managed the stories and burn down using TFS. Each day we’d have a 5-10min discussion of the project and include the product owner via a phone call. There was a daily burn down chart emailed out to the team, and at the end of each iteration a demonstration of production-ready code was shared with the customer followed by a retrospective that drove continual improvement of our process.

We learned to love running projects this way and saw how product quality and team communication improved.

Going Forward

How much of this process should we bring forward into our side project? I don’t think we’ll be doing daily meetings – we both have young children and will be doing very well to spend 8 hours a week on this project. Having a product backlog and burn down seem like a good idea to me, but having a time-boxed iteration will need to be tested. We’ll need to find a new process that works for us, so we should definitely keep a periodic retro schedule.

Why are we doing this project? We both enjoy Disc Golf and we both enjoy learning and working together. This project will give us the chance to try some new technologies and approaches, and keep us interested in learning.

What’s next? My next step will be to look into opening up an account with Team Foundation Service to see if we can use an environment that we’re both accustomed to. We’ll create a product backlog and plan out our first iteration. Who knows where it will take us!

blog comments powered by Disqus