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.

1

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.

  • 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 Aug 13 '14 at 2:08
  • @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 Aug 13 '14 at 4:17
0

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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