2

I have a sprint with 2 developers. IOS and Android In this sprint we have estimated 50 hours for IOS developer and 10 hours for Android.

Logically Android developer will finish much earlier. However Burn Down chart will still count his man-hours for further days and will say that we are working too slowly.

How do you balance this kind of situation?

2 Answers 2

1

There seems to be multiple issues in the way you are implementing agile.

  1. Stories should never be estimated in hours, but only in more abstract units. There are different techniques, but the main gist is that time is never estimated explicitly. In agile, time is fixed and scope is variable: estimates are used to understand how many stories we can fit in an iteration, not how long each will take.

  2. Agile teams must be self organizing: thus, you are asking the wrong question here: if the team has forecast they will do 10 units of X and 50 units of Y, you should trust them to get the job done, and not try do second guess or micromanage their time. Are the team elements going to cooperate on some stories? This could account for the unevenness of the estimate.

  3. Agile teams must be cross functional: the stories are accepted by a team, at which point the team is responsible for getting them done. If you assign stories individually you are not doing agile: stories are never assigned, and are never the responsibility of an individual.

2
  • 1
    Thank you for the answer. What can be the alternative here if I must manage each member? Should I have different burn down charts for each? Because both resources are doing same product but on totally different platforms, so they don't have anything in common.
    – Edgar F
    Feb 24, 2014 at 15:58
  • You have two options: two platform teams (and two burndowns) or one multi-platform team (and one burndown). In the second case, your developers will need to evolve to be cross-platform.
    – Sklivvz
    Feb 25, 2014 at 9:00
0

The situation your in essentially is that you have more manpower available during the first part of the sprint. Its the same if some developers would go on holiday: The work power is reduced after that point. This will result in a slower velocity for the second part of your sprint. You can reflect this in the burndown chart!

Let's assume your workers work with 10 units/week. Then you will get 20 units done in the first week and 10 units done in the 4 subsequent weeks. When you draw the assumed velocity into the burndown, you can consider these numbers. Then you will still see whether or not you're on schedule.

Anyways, I think Sklivvz has a point here... what's you Android Developer going to do during the rest of the time? Twist thumbs?

2
  • The developer would go work on another project. Let's say if all resources are outsourced freelancers
    – Edgar F
    Feb 25, 2014 at 11:59
  • It seems like the iOS and Android things are not related, am I right? In that case, why do you manage them as one? Split them up, manage the progress on each of them separately. Why doesn't the Android developer get more work into the sprint?
    – Sven Amann
    Feb 27, 2014 at 10:27

Your Answer

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

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