We have up to several team members that does not work 100% on our team. You might argue that this is a bad idea in the first place, but lets assume we can’t do anything about it. I have had a discussion with one of the other team members, and my argument is that the burndown chart is “lying” to us. Let me give you an example.
Lets say we have a sprint, lasting 2 weeks.
We have 6 members, where 2 of them are only working 50%.
If both of the part time members work 100% the first week, and 0% the second week, my argument is that after 1 week, the burndown will look alot better than the reality is. Scrum says that this is the time to add features to the sprint.
Ive seen an alternative way to do this, where you beforehand type in the days you are available, and then have a nonlinear ideal line. My first suggestion was to have placeholders to burn down even if you were not available, but that was shot down pretty quickly.
So I wonder; Should we do anything with the burndownchart? Is the chart even useful? Are there other good practices to overcome this hinderance?
We are currently using Urban Turtle
Regarding the part time developers – obviously, it is not an ideal situation, but there isn’t really much of a problem with it. Would Scrum fail if one of your team member wanted to take a day off and would be available for only 32 hours out of 40 in one week? Would Scrum fail if during the week of Christmas nobody would be working? No – on both accounts.
Here’s the simplest (and in my opinion best) way to handle your situation: you simply add up the hours that all of the team members will be available for work in that Sprint, e.g. if you have a team of 3, with one member at 100%, and two at 50%, and the sprint is a week, you will add up 40 + 40/2 + 40/2 = 80. That is how many work hours the team has to commit to. It is no different than if you had two full time members.
Regarding the burn down chart – I think that plotting a non-linear “ideal” burn-down is both a waste of effort, as well as misguided. There’s a reason it is called ideal. It is not because you must strive to work on that line, but to demonstrate what the burn down would look like if you would (could) work at a constant pace.
Remember the function of that graph – it is there to indicate possible problems in the development. Not every deviation from the ideal is bad. Life isn’t ideal, and you are fooling yourself (and harming yourself) if you get worked up over the difference.
In fact, trying to account for every deviation is exactly the predictive method that waterfall famously fails for, and that agile methods try to get away from.
What you may want to do, is to note every major deviation, that you had, understand them and see if there is something you can do about them, and then adapt your process. That is better than trying to model the current state.
So to answer the last question – Are there other good practices to overcome the hindrance – the answer is it is not a hindrance. Overcome it by accepting your reality, and ignoring that which is wasteful.