By Peter Bell

Solo Scrums

No matter how small your development team is, I think you can get benefit from doing Scrums. I've just adapted a Scrum process for upgrading my in-house framework. I'll be the only developer on the project, but already I love the visibility that it is providing. Here is a (very abbreviated) summary of the process I'm using based on the excellent Scrum and XP from the Trenches (PDF) article but modified for the idea of Scrum for a solo developer . . .

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 :->

Product Backlog
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!


I think these are definitely good practices to follow. But, be wary of calling not-Scrum as Scrum... there are plenty that are really vocal about not liking it (to put it nicely).
# Posted By Sammy Larbi | 6/18/07 10:42 AM
Hmmm, interesting. To be fair I haven't hung out on the Agile lists, so I'm not really sensitized to this.

So, I suppose the obvious questions:
- What is the absolute minimum number of developers required to call it a Scrum?
- If a single developer can do scrum, what would be required for it to be scrum? Product backlog and sprints for sure along with demo (even if just to self or client). Morning meetings seem like a good review process . . . in short it seems to me like scrum is possible for a single developer and would be broadly similar to my intent (although to be fair I didn't list all of the items).

# Posted By Peter Bell | 6/18/07 10:57 AM
I'm using Scrum on a team of two developers (me and one other) plus a Product Owner. Even though a two-person team is way different than a one-person team, many of the "scrum on a small team" challenges are the same.

Like you, we started out with the "Scrum in the Trenches" doc and adapted things to fit our needs. Here are some things that work for us:

We do 3 week sprints, and that works well for us. In Scrum, the purpose of a sprint is to deliver a buildable, demo-able, functional iteration of the software, and we generally need more than a week to do that. (Of course, on a multi-person team the overhead of the planning and review sessions can be significant and wouldn't be justified with one week sprints)

Do you find that you can produce meaningful iterations of the software with a single week or work?

We do all product backlog estimates in "ideal man hours", which is how long something would take if we were _never_ interrupted by sales, to do support, to talk with a co-worker, etc. To prevent product backlog estimates from being too fine-grained, and to avoid suggesting a level of accuracy that doesn't exist, we estimate in chunks of 4 hours: a product backlog can be estimated at 4 hours, or 8 hours, but not 6. (In our system, it's rare that something with true business value can be checked out, changed, tested, and checked in in much less than half a day, so this works for us)

When planning the sprint, we do detailed task breakdowns for the top x number of backlog items. The sprint tasks are also estimated in ideal man hours, but can be more granular than 4 hours.

When you say most of your backlog items are around 2 hours, are those "product-level" items (things the customer cares about) or "task-level" items (individual pieces that contribute to a product-level feature)? If it's the latter, you might want to experiment with more granular backlog items to see how it changes your process.

I mentioned that our estimates are all in "ideal man hours", but those don't exist "in the wild". We use a "focus factor" to help account for all the interruptions we will invariably have. When we plan a sprint, we multiply the ideal man hours available in the sprint (40 hours * 3 weeks * x developers) by a percentage such as 0.8. That calculation tells us how many hours worth of product backlog items we can commit to for the sprint.

After each sprint, we compare our actual velocity [what we got done] against the total hours available to determine our actual focus factor. We then use that information to adjust the factor for the next sprint.

This same approach might help you fine-tune your planning, taking into account the interruptions of running a business. The focus factor idea is straight out of the Scrum In The Trenches doc, I think its around page 37.

This turned out longer than I'd expected, but hopefully it will give you some additional ideas to toss around!
# Posted By Seth Petry-Johnson | 6/18/07 11:41 AM
re: the Scrum Police and calling "not-scrum", scrum.

I'm on the pragmatic side of that fence. Scrum is all about communication and agility with respect to change requests, and if you bastardize "true Scrum" to fit your needs I think that's fine. Like all things though, make sure you understand why a rule (or concept) exists before you go and break it.

If you're interested in Scrum, check out His intro articles on scrum helped my team understand the process.
# Posted By Seth Petry-Johnson | 6/18/07 11:44 AM

Great comments - many thanks!!!

To answer your questions, yep, I can get a lot done in a week. I typically sit around thinking about stuff forever and then code it in no time flat. I wrote the core of my dependency injection engine in under 8 hours, I wrote a simple but powerful data mapper in a day, I wrote a generic application generation system in a long afternoon, I've written a newsletter system from scratch (no real RAD tools or scaffolding) in 1.5 days, I wrote a simple config driven Active Schema tool in 3 hours and usually figure that if I can't solve a problem in a day I'm either doing something too big or I don't really understand what I'm trying to do well enough to do it quickly and elegantly.

Interesting question re: granularity. You're probably right that about 4 hours is the minimum time to create a useful feature. I typically break it down into 2-3 smaller tasks - often "specify X", "rough out X", "test and demo X". I find breaking down into smaller chunks gives me a bigger sense of accomplishment, but it also allows me to know if I'm running slow more quickly. If I have one hour to spec a feature, when I get 50 minutes in I know I either need to finish up, speed up or gear up for a long night! I guess it is like driving a car - I like to make lots of smaller adjustments, but I certainly agree I wouldn't want to manage a second person that tightly - it'd drive them nuts (it'd drive me nuts if someone else was managing me this closely). I guess this is where the solo approach is actually a combination between team management and tools for motivating yourself to be more productive, so I'd imagine the "right" approach for an individual developer would be much more variable based on preferences.

I looked at the focus factor idea in the PDF but it didn't really work for me. The problem is one week I might have 80-90 hours of distractions if a server farm blows out or I have to do lots of sales presentations or something. Another week I'll get only 5-10 hours of distractions and while I could compare averages over a year I wouldn't get really good visibility on how well I'd done in a given week with an averaged focus factor. How would you feel if you worked really productively for 90 hours in a week, looked at your achievements and saw you'd only hit 20% of target due to 80 hours of distractions?! I needed something I could tune a bit better than a general focus factor as my schedule is so variable.

Many thanks for the inputs though - great to see what others are doing!
# Posted By Peter Bell | 6/18/07 11:57 AM
Thanks for the link!
# Posted By Peter Bell | 6/18/07 11:57 AM
@Peter: I'm not sure if there is a minimum number of developers to have a scrum, but I think you need at least a Product Owner, Scrum Master, and Team (the team could be one person, I suppose). However, I'm not sure how you could have a daily standup meeting with only one person, which I think is a core element of Scrum.

But, you can still take all the other ideas and use them to your benefit. We do that here. We sometimes have a Scrum Master, and don't have a PO at all times, but the rest of it we do fairly faithfully.

@Seth & Peter: I'm with you on the pragmatic side of things, and I try to avoid fights about what a term is or means unless it will aid in understanding something where we were having trouble understanding each other.

In this case, I feel I have an understanding and I could really care less that Peter may have called something that might not be Scrum by the Scrum name. I just wanted to point it out because someone may be offended that he did so (if in fact he did), and be very vocal about it. Most in the Scrum community aren't like that, and in fact are more pragmatic, but as in every other community, you will undoubtedly find pedantically inclined who aren't so nice about it.

I also recommend Micheal Vizdos' site - I've found it useful in explaining some of the terminology in a fun way.
# Posted By Sammy Larbi | 6/18/07 12:40 PM
@Sam, thanks for the clarification. Question: why NOT have a single person stand up meeting? The intent of the meeting is to go over progress and status with th team quickly and efficiently. In what way is that different to a single person quickly and efficiently reviewing their own progress?

I'm starting to think that what I'm talking about IS Scrum. Is there a requirement for the product owner, scrum master and team to be anything more than facets/concerns all of which a single individual could embody?

Just a thought . . .
# Posted By Peter Bell | 6/18/07 12:55 PM
"Is there a requirement for the product owner, scrum master and team to be anything more than facets/concerns all of which a single individual could embody?"

There's a forum at the Implementing Scrum site where you may get a few responses to that question.

From my experience so far, however, the answer is "YES, there is a difference", at least between the Product Owner and Scrum Master. You can be a Chicken, or you can be a Pig, but you can't be both. (Read Implementing Scrum if I just lost you)

In my team, I am both the Scrum Master and a Team Member. We tried having the Product Owner play the SM role, but it didn't work out so well. It's much cleaner to have the SM and PO be different people.

Of course, this is probably all moot in a team of one person... if you're serious about doing solo scrum, I'd just focus on the artifacts that are useful (backlogs, burndown charts, etc) and not worry so much about making sure each role is represented.

Just make sure that, if you ever add another person to the mix, that you re-evaluate your processes at the same time.
# Posted By Seth Petry-Johnson | 6/18/07 1:06 PM
Hi Seth,

I know what you mean re: chicken/pig, but I'd argue that while it is ideal to have two different people championing the two different concerns, it is possible for a single individual to do both in the same way that a developer can also be a sales person. They just have to be very clean on changing mindsets - I find even silly things like different seats or physical locations for championing dfferent perspectives can keep you "in role". Obviously better to have more people, but better to have one person taking turns between explicitly playing different roles than one person not making that distinction :->

Very good point about re-evaluating structure when adding to the team as you're right that a number of the decisions wouldn't be optimal if I doubled my team size!

Thanks again.
# Posted By Peter Bell | 6/18/07 1:16 PM
@Peter: To address your two questions:

"why NOT have a single person stand up meeting?"

I don't know. I never really thought about it - I guess initially I thought the idea sounded silly, but I guess it could work in practice, to have a time of day you reflect on what you did yesterday, what you are going to do today, and what is holding you back.

"Is there a requirement for the product owner, scrum master and team to be anything more than facets/concerns all of which a single individual could embody?"

There was a conversation a while back on the scrum development list about this, and the answer was definitively (assuming my memory is correct) that Scrum does need the different champions to work well. Of course, you may find that they aren't very useful to you, but I think it needs to exist to be "official," if there is any value in being "official" in the first place.

I find the roles useful when we have someone to play them, and I think most people do, but I don't know if there were truly a one-man scrum organization why that guy would need to hire someone to do those things for him.
# Posted By Sammy Larbi | 6/18/07 2:27 PM
Hi Sam,

I think you're 100% right about the importance of roles. When one person tries to look from both customer and developer perspective they tend to make trade offs unconsciously. The trick is to specifically take one role at a time and play it 100% and if you can "step out of yourself" enough to be those different people then a single person can play multiple roles. It's always going to be better with multiple physical stakeholders, but it is possible and valuable for a single developer to take turns playing the different roles, "walking in their shoes".
# Posted By Peter Bell | 6/18/07 2:45 PM
Thanks for the post, really interesting to hear how you've successfully adapted Scrum to fit your single-person-team situation. As for the question about whether or not this is Scrum - does it really matter? It works for you right?

Here's my take on the "Scrum compliance" issue. It is not about doing all the practices and checking them off. It is about understanding the purpose and benefit of each practice, and achieving those benefits. If that means modifying or even removing some practices, that's fine as long as you still achieve the benefits.

For example the sprint demo is to ensure that there is something to deliver, and that stakeholders can see and give feedback. If a team (or one man show) can achieve that without a demo, then fine. Same with the daily standup meeting - that meeting is to ensure that everybody on the team knows what's going on. A one man team doesn't need a meeting to achieve that :o)

Anyway, good luck and glad to hear that my book has helped.

# Posted By Henrik Kniberg | 7/15/07 5:08 AM
Thank-you for sharing this info.

I think I'd like to try out Solo Scrum. I read 'Scrum and XP from the Trenches'; I like this part:

"Some teams have a can of coins and bills. When you are late, even if only one minute late,
you add a fixed amount to the can. No questions asked. If you call before the meeting and say
you’ll be late you still have to pay up."

so does this mean if I a late to my scrum I get to put a dollar in my beer fund..? :)

Seriously, I found your BLOG article, the comments and the PDF "Scrum and XP from the Trenches" very useful!

# Posted By Ben Kenobi | 7/15/07 5:48 AM
Henrik- You said "It is about understanding the purpose and benefit of each practice, and achieving those benefits. If that means modifying or even removing some practices, that's fine as long as you still achieve the benefits. "

I'm certainly not one who places value on the names of things, but rather on the results you achieve and if they are good, then they are good (but you might still ask if you can be better!) So, I agree with you here.

But, if they've never tried it "by the book," "how do they know?" (I forget who I'm quoting here)

In any case, yes the point of the practices is to achieve some ends, and if you achieve those ends then who cares much about the means?
# Posted By Sammy Larbi | 7/15/07 11:29 AM
@Henrik, Many thanks for the comment (and the wonderful book!). It was great to see your real world comments on how you were using this and made it much easier to adapt the practices for my use case.

@Ben, Glad you enjoyed! Interesting question, because my first thought was "how can I be late to a meeting that only I am going to attend". However, with client calls, procrastination and the like it is all too easy to blow off "meetings with yourself", so I think a dollar into a fund every time you blew off or postponed such a meeting would be a good idea. Personally, though I'd consider donating it to an organization you violently disagreed with - that way you'd have plenty of motivation to make the meetings!
# Posted By Peter Bell | 7/16/07 9:28 AM
Thank´s. Very useful.
# Posted By Roberto Nunes | 9/5/07 2:57 PM
Thanks a lot for this solo approach to solo scrum.
I have a 2 week project ahead starting Monday and will try to use / implement your ideas.
# Posted By Alexis Perrier | 11/30/07 12:22 PM
Hey Alexis - Cool - please post a comment when you're done and let me know how your experience was!

I'm also finding tooling to be key to the whole process. I'm finding the integration between svn, Trac and Mylyn (in Eclipse) is really helping me to manage tasks as I come up with them and provides a nice motivation as well as good documentation about what's been done.

Any tooling you find helps for managing user stories and the like? I was looking at Mingle from ThoughtWorks, but haven't had a chance to play yet . . .
# Posted By Peter Bell | 11/30/07 4:28 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.