Firstly a disclaimer - I am completely new to Scrum. This isn't a set of recommendations from someone with much experience (although it was based on advice from people with deep experience). It is a first cut at a simple approach to Scrum for a solo developer and it is really the outline of a proposed experiment (which I'll be performing on myself later this week). Anyone with any advice, comments, experience or opinions, please comment at the bottom of this posting so we can all learn something new :->
The starting point for implementing Scrums is to develop a prioritized list of outstanding requirements - in my case features (as in customer valued functionality) that the new version of SystemsForge must include. I document my backlogs with an ID (auto-ID), Title (2-10 words distinctly distinguishing this item from any other), Short Description (1-2 paragraph clarification of requirements/constraints), Importance (an integer - can be any number - the bigger the more important - I'm using widely separated numbers so we can easily fit other priorities in-between without having to renumber), Estimated Hours (estimated man hours to complete) and Demo (a short description of how you'd demonstrate it was working). Most teams use estimates based on man-days. I have sufficiently constrained resources that it is more meaningful to estimate in hours. It also allows for finer grained tasks if you want to document important tasks that will maybe only take an hour or two to complete.
I have found the process of listing and estimating the features to be invaluable. I'm doing a re-write of an existing system so I have been thinking about the architecture for a long time and was able to break this down into lots of nice discrete little 1-3 hour projects, but it still really helped me to make all of the dependencies and priorities explicit so I could focus on delivering as much functionality as efficiently as possible.
Scoping the Sprint
Scrum is based around periodic sprints where a group of developers (usually less than fifteen) takes a time period (often a week or two) to knock out a set of prioritized user stories/features. In my case I have a single developer (yep - that's me!) and want to see what can be accomplished in a week. Unlike most dev teams, I also have to handle some elements of running the business, legal issues, marketing, client phone calls, specifying new projects and keeping an eye on our hosting infrastructure, so I really don't know how many development hours I'll have in a week, but I'm going to assume I can dig out 30 product hours this week (the flight to the US will help - that is almost 8 interrupted hours on its own including airport time!). So, I have picked 30 hours of estimated product work for my first sprint.
Luckily I've re-written most of the functionality so many times now that I'll be able to implement a lot of features in 30 hours (I'm hoping to rebuild the complete framework and a good chunk of the generator before next Saturday). Obviously I'll know better by next Saturday how close my estimates were, but if nothing else I'm going to get great feedback on my estimating skills!
How are We Doing?
Because I have very constrained resources and lots of potential distractions I need to know if I'm off target as quickly as possible. For my use case, waiting a week to see how I'm doing is way too coarse grained. I've got to have nightly visibility on my progress, and I need to track two distinct things. Firstly I need to track how well I'm doing on finding the time to work on the project and secondly I need to track how well I'm doing on getting the project done.
For getting visibility on effort (time spent), I'm budgeting a number of hours every day, tracking time spent and running a simple red/green check on both daily ability to find the necessary hours and (more importantly) cumulatives for the sprint so I know early in the week if I have to cut down on non-essentials like sleep to fit the project work in!
As for tracking results (progress on the project), I've decided the best solution will be to count the total of the estimated hours for all of the completed tasks and to count that as my "achieved hours". So, if the first five items are estimated as two hour features, if I'm done with them in ten actual project hours I'm dead on track. If I'm done in eight hours, I'm running at 25% ahead of estimate. I'm just going to call this velocity as it has the same intent as that term, but I'm going to use a percentile so 100% of velocity is right on target, 125% of velocity means I'm going faster than planned (if I do 10 hours of estimated work in 8 project hours) and 50% of velocity means I'm taking 20 hours to complete 10 hours of estimated work and need to seriously improve my estimating and/or productivity and to find more hours to get the project completed.
This is quite a different measurement process than those you'd use if you were running a team. I think this kind of micro management of a team would lead to the same outcome as raising the Kings taxes on tea(!), but for managing yourself if you're sufficiently motivated I think it will provide really tight visibility. It's the kind of process I'd recommend for contractors who are working individually on smaller fixed price projects and want to get the projects done quick so they can make more cash or take the weekend off.
Obviously a lot of elements that relate to Scrum are irrelevant in a single person team, but I have definitely found product backlogs to be useful as is the idea of a sprint. I'll try my time tracking experiment and if anyone is interested, I'll let you know how it worked out next weekend!