27809Re: [scrumdevelopment] Re: Estimating When Several Platforms Are Involved
- Mar 4, 2008Hi,
>>> Well, the first time they might take 10 times longer. However, isn'tSorry was not clear enough. We do estimates/SPs for the 'team' doing the work for each story, but those estimates assume the people who will do the work are skilled and experienced to do do it, if the work was to be done by the 'unskilled' people, the estimates will be worthless as we would be wrong by an order of magniture. As a team we might be able to do 6-8 stories in a sprint, if we all swapped roles, we would struggle to get one done.
>>> this better than having nobody work on the backend code?
>> Not really. Firstly, it is going to mess up the estimates,
> So????!!! Estimates are a means to an end. Of course, they're based on
> the person doing the work.
> If the newbies are doing the work, ofWhich is why we want the skilled people to do the work, and not the newbies :-)
> course the estimates will be higher, reflecting the fact that the work
> *will* take longer.
> If the other team members do the work it
> probably will take 2.5 times as long.
>> Secondly, the 'real' backend guys would need to spend time trainingI don't think we are in a mess at all. The only really problem we have is how input into the sprint planning process the fact that there is different workloads for different people when we are only meant to be producing a single 'Story Point' number for each story.
>> and mentoring the 'new guys' as well as code reviews and rework, so
>> will be spending less time doing what they are doing.
> Yes, it's a price that you'll have to pay someday if you ever expect
> to get out of this mess.
> Either everyone gets cross-trained now, with itsThats not quite correct in our case. We have our staffing levels just about right in that over the life time of a project, there is the right amount of work to keep everyone busy full time, but in prioitising stories on 'business value' alone means that some sprints some people are light on work, and the next, they have too much. For the last two projects we have been prioritising stories about 80% on "business value" and about 20% on balancing the workload, which maybe the best way for us, but others might handle it differently.
> associated cost, or the team will continue to run on fewer cylinders,
> since there will never be a perfect balance of features that keeps
> every gainfully employed in their preferred specialty.
>>> How is this any different than having a junior developer inWe never have a problem filling senior positions, I think the people who do are trying to hire senior people for junior salaries. I very much agree with Martin Fowler on his "Cheaper Talent Hypothesis" (http://martinfowler.com/bliki/CheaperTalentHypothesis.html)
>>> the backend group?
>> Its not, thats why we don't hire junior developers :-).
> Yup, I thought so. :-) It sounds like the company would rather have an
> open position go unfilled for years because you can't find a senior
> developer, when you could have hired a junior person and taught them
> the skills they need.
> Any task that goes unstarted because the person with theThe problem here is there is a real danger that 'taking a stab at it' is actually worse than not doing it at all, as the 'expert' will at the very least have to review all the work, and at worse have to redo it as it is total tosh.
> expert skills is unavailable will be better served by having someone
> minimally capable take a stab at it.
> Once again, this is where agile development requires a change ofIts the 'eventually' bit that is the problem. I personally think "eventually" is several project lifetimes.
> mindset. While a group of experts can certainly be productive, as you
> point out above, a group of cross-trained developers can eventually
> become more productive, as no task goes wanting for a developer.
> What happens if one of your experts gets run over by a car? ItWe have lost 'experts' to serious illness, we re-priortised the PB to take account of this whilst we hired another 'expert', but being 'Agile' allowed us to do this with minimal impact.
> happened to us a month ago. Ouch. Is there someone to step up?
> I'm sorry I didn't solve your problem. You came looking for answers toIts not that I don't like the answer, its just it not an answer that will work with us :-)
> your scheduling problem, but you didn't like the answer.
> I don'tMaybe, maybe not, but no harm asking :-)
> believe anyone else will have a solution, either.
- << Previous post in topic Next post in topic >>