Scrum - How should part time developer's progress be visualized in the burndown chart [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

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

Answer 1

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.

Answer 2

Your situation is a perfect candidate for using story points over hours. The relative combined effort to complete a story would be more meaningful to your teams ability to deliver value over time, regardless of how much time has been historically spent on similar stories.

There is a very well known anecdote about this situation that turns the situation on its head. Imagine you had a full time team and you knew exactly what hours they could work. Imagine your team had the best scrum practices and you reached a velocity everyone agreed they were happy with. Are they now confined to that velocity forever? Is it conceivable that if you set the same team the goal of delivering the same velocity in less hours and offered the incentive of simply going home early, could it be achieved?

The answer is yes. In fact a real life scenario like this occurred at a major US software house and that team actually got their working week down to 16hrs!! Yes, 16hrs!! They did it by continually fine tuning how they viewed effort. After all, if you take hours to compare stories rather than comparative complexity, how do you factor things like reusable components or cope with unexpected requirement changes from one feature to the next?

Switch to story points, you'll never look back :0)