0

I've been using Scrum for ages on my own projects, which are usually part-time (couple of hours per week -- maybe up to 10 hours a week) and usually solo (although occasionally include teams of up to 3-4 people).

I like certain benefits which I get from using Scrum:

  • Centralized backlog of work (previous, current, and future)
  • Breaking down work into small, user-facing packages (stories)
  • Quick/cheap estimating of stories

Some issues that I struggle with:

  • Estimating stories seems like a waste, especially if I'm the only developer, there's no concept of a release/goal/deadline.
  • Sprint velocity swings drastically. For example, if I get sick, it drops to near zero; if other commitments back off, it can double.
  • I end up changing story velocities often to try to reflect "real" effort (not estimated effort), especially if they were off by more than one Fibonacci number (eg. 3 => 13)

Trying to use velocity for capacity planning ("how long will it take for ...") is almost impossible. In fact, other than breaking work into smaller pieces, it's mostly overhead.

Is there a tweak or better way to get meaningful velocity under this kind of situation? Longer sprints may work (average out better, eg. one month), but I'm still not sure that my velocity is actually meaningful.

Improve this question

4 Answers 4

Reset to default
3

I've found that "scrum" can mean very different things to different people. To me what differentiates it from other agile processes is the focus on commitment based sprints. Since you have not listed delivering sprint based deliverables as an important benefit for these projects you might get more value out of other lightweight agile processes rather that sticking to the activities prescribed by scrum.

Estimating stories can have limited utility. I've found that if you're good about keeping stories small and about the same size then it works just as well to count stories instead of points or assign all stories the same point value as soon as you believe they are well defined. I've even have team projects fall into this pattern and we spent "estimation" activities getting stories to be appropriately small rather than debating point counts.

In order to get a useful velocity I think you should try to measure points or stories delivered per hour across each iteration. That should eliminate much of the variability you are seeing. If the time you spend on each iteration is highly variable then you won't be able to project a completion date but you should be able to project roughly how many hours of work remain.

Many tools include the ability to adjust team strength per iteration to account for these sort of changes. For example Pivotal Tracker allows you to set a percentage of normal team strength for each iteration which allows you to account for team members on vacation, reduced hours, or other variations. Alternately you might count an iteration as X hours of work rather than Y days elapsed and an iteration could take 1 to 3 weeks to complete but you'll get a more useful estimated number of iterations remaining in the project.

Improve this answer
2
  • Thanks for your answer. Can you please clarify 1) what other lightweight agile processes might benefit me more, and 2) isn't the point of using points to get away from estimates in hours?
    – ashes999
    Commented Aug 13, 2014 at 2:08
  • 1
    @ashes999 I was thinking of XP and kanban style processes both of which focus more of the flow of delivering stories than on stories per iteration. I don't think you should estimate in hours, keep your points. Just track hours spent on the project rather than assuming that every iteration is equivalent. A 5 hour week which delivers 5 points and a 10 hour week which delivers 10 points should give you the same velocity. Given that you should be able to predict what will get done next week if you expect to have 8 hours available.
    – Jonah
    Commented Aug 13, 2014 at 4:17
2

The value of Scrum starts with a dev. team of minimum 3 people and is actually felt from 5 people onward. If you are the only developer, I would not bother with Scrum, you can get inspiration from it, but really it boils down to a good features prioritisation and personal management.

Improve this answer
1
  • Hi. Although your answer explains what I shouldn't be doing, it needs more information on what I should be doing.
    – ashes999
    Commented Aug 13, 2014 at 9:22
0

Estimating stories seems like a waste, especially if I'm the only developer, there's no concept of a release/goal/deadline

This might be where you get the most bang for your buck. It might seem like a waste of time, but if you do your estimations you'll be able to see how much you should take on for each sprint.

In lieu of Story Points you might want to use Hours for your estimations. I know points are generally the accepted choice, but if you don't keep regular hours I don't know how your velocity will trace to anything meaningful.

At some point, no one's going to have an acceptable answer for you -- if the scale of your work gets so small that any variation in your personal schedule makes any metric meaningless, then there's not much you can do about it...

Improve this answer
0

You can successfully use Agile being one person or more. Barnaby Golden once told me

You can adopt agile with any size of team as it is an approach to doing software development.

When it comes to Scrum, like you mention, it is advised for teams of at least 3; also, using Kanban with just 1 person can have outcomes far from expectations.

Still, someone felt the need to create an Agile methodology for solo developers called Cowboy - which i think it suits your needs considering you're most of the time just one and you like certain Agile and Scrum practices. This methodology, as it's claimed in the article

borrows heavily from Agile practices as well as XP, Scrum, AUP and Real.

By using Cowboy you'll basically

  • use TDD
  • develop in small-iterations (no longer than 2 weeks)
  • add features and bugs from previous cycles to the new one
  • have a Scum-like backlog
  • have a lot of contact with the client as he/she will be responsible to discuss and specify the requirements as needed

To read more about it go through pages 18-24 of the document.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.