Using Scrum on a "Personal Time" Project

Question

Hi,

I'm starting up a personal project to develop some open source software. I want to use Scrum as the PM process on this (as I like the Product Backlog, prioritisation, and if I can get them, the burndowns) but it seems to me that I won't get the full value because I can't at the outset guarantee the amount of time myself and my collaborators will be able to commit to work during a given sprint.

I know there are other benefits that I will still get from using Scrum but are there variations or tricks and techniques I am unaware of which will enable me to get the value of things like burndown charts and timeboxed iterations? Or am I just being too hopeful?

TIA.

Regs, Andrew

Answer 1

In a by the book setting you won't use real time for calculation of the burndown chart but rather story points. After a few sprint you will see an average velocity and thus be able to generate a burndown chart and use this velocity for commiting to the sprint items.

And I strongly disagree with warrens post on the scale-down point. The main problem I see is a strongly varying velocity between two sprints, since it is only a hobby.

Answer 2

As this is a hobby project, are you actually concerned about deadlines? How much value would it in fact give you to know how much will be done after a Sprint?

If your answers are no, you might want to look at a kanban approach as an alternative.

Answer 3

I think that each member of your team should commit to a minimum number of hours. If they have more to give to the sprint, then they take additional tasks on stories in the sprint. Or, grab other stories from the backlog to work on.

That way there is at least some "commitment" from the team. And if they have more time, great!

Answer 4

When the amount of time the Team is able to put in at every iteration varies too much, the velocity cannot really help to plan the Sprints since it will vary too, especially at the beginning. However, the average velocity may start to stabilize after several Sprints.

Nevertheless the burndown charts will be useful still as they show an accurate status of the current iteration.

You'll also take advantage of the estimations "calibration" Agile processes bring.

Answer 5

I think about agility in software development and come back to three aspects which provide real utility:

• A known backlog of tasks to do
• A regular opportunity to openly discuss the current status of tasks being addressed and hurdles to overcome
• Team-managed iterations that result in a working subset of the eventual full product

In a work environment, say my 9 to 5, it is easy enough to adopt such a methodology. You've got devs who will be there at least 40 hours a week, every week and so there are few barriers to engaging in an agile practice, like Scrum.

In "after hours" settings, commitment levels of participants often vary. That's life. So you work with what you've got. If Matt is excited about the project but his schedule is busy and the number of hours he can dedicate to the project will fluctuate a bit, so what? If he's "on board" and serious about the time he is willing to invest in the project, then it is just a manner of planning your iterations accordingly.

I personally wouldn't get wrapped around the axle about this, though. In the end, Scrum or any 'agile' process that you adopt should be a means to an end, not the end itself. Particularly in an environment where conditions will differ from those in the 9-5 world, you need to be flexible in your iteration plans. You still plan your work and work you plan and engage in the regular communication and the "where are we today?" exercise to keep everyone in the loop.

The goal is solid software - if you can't get a lot of utility out of a particular aspect of Scrum, or any process, so what? You'll likely develop a hybrid process anyhow. I wouldn't get too too concerned about getting things like burndown charts and velocity and all that. I honestly think the focus needs to be more on quality software being developed and less on the artifacts that might help down the road in the next iteration or the one after that. That's my opinion though.

My advice is to use the things that work and keep it simple. Backlogs are great and the daily 'meeting' to touch base with everyone - even if this is a virtual one done by IM - is where the real value is found. Hobby or side jobs are tough things to commit to and I wish you well with it. But be open to the fact that it might not work as well as the process would at the 9 to 5.

Answer 6

The problem with Scrum for this sort of project is more around the type of development team structure that Scrum is designed to support, in particular the colocation of the team for the daily standup meetings. Its hard to have a daily standup meeting when you aren't at the same physical location. In addition, I doubt you will have a Product Owner on your team, and you will be both the Scrum Master and a developer. On top of this you and your other developers will be working at different times and days may go by without any work being done at all. This may make coordination of the team difficult.

Every project, regardless of develoment methodology, should have a good idea of what needs to be done (the product backlog), what needs to be done shortly (the sprint backlog), and how long it will take to do these tasks so you have a reasonable estimation of how long the project will take (the project velocity and burndown). It is the other parts of Scrum that you may have problems with - not being colocated for meetings, the lack of a Product Owner, using a notice board to show the sprint status, etc.

This is not to say you can't modify the Scrum process to suit your purposes. For example:

• have video conferences/Skype calls/IM meetings at prescribed times several times a week even if nothing has been done. Daily is probably too often for this type of project but maybe three times per week would work for your team.
• use a web based issue management system so you can all see the product backlog, know what the sprint backlog is, and know what people are working on
• have set sprint lengths (say, 3-4 weeks) so that the developers can sense the momentum and know the deadlines
• understand what time is being spent on development so you can work out your project velocity and what can be acheived in the next sprint. This may be hard as available time will vary from sprint to sprint.
• have retrospectives after each sprint so you can tune your development process with respect to what went well and what didn't. This would be the ideal time to meet at the same physical location if possible.

Scrum, at its essence, is mostly about effective communication so if you get that right you should be able to make a modified version of it work for you. Just remember that communication reduces in effectiveness down the list of

• In person
• Video conference
• Skype/phone/voice calls
• Instant messenger
• Email

so try to use the most effective method at your disposal for your meetings.