Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
There seems to be multiple issues in the way you are implementing agile.
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.
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.
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.
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?
