Hi,

This question is what to do / talk with your team members when the project is delayed due to constant delays on the development of the planned tasks?

We are using scrum, and we are estimating times for sprints. Short tasks, short sprints.

But developing the tasks are taking far more time than the original estimated time. We have only been 6 weeks in production and the project has already "2 weeks late". The problem is only with the progamming department. Art and Design is going very well.

What should we do?
What tips / recommendations do you have?

Thank you in advance.

Various things which may or may not be applicable:

Make sure goals can actually be accomplished in one sprint; if not, split the task into smaller chunks.
Avoid design changes.
Avoid meetings if everyone knows what they should be doing, or narrow the meeting participation to people who only need to be there.
Have someone see if there are any inefficiencies in day-to-day chores (compile times or other cases where people are waiting for something or someone else before they can continue working). Fix these if possible (you may need to have one or more programmers focus on fixing inefficiencies for a while before gains spread to the rest of the team).
Start cutting features.

Hi,

This question is what to do / talk with your team members when the project is delayed due to constant delays on the development of the planned tasks?

We are using scrum, and we are estimating times for sprints. Short tasks, short sprints.

But developing the tasks are taking far more time than the original estimated time. We have only been 6 weeks in production and the project has already "2 weeks late". The problem is only with the progamming department. Art and Design is going very well.

What should we do?
What tips / recommendations do you have?

Thank you in advance.

It sounds as if the project manager is underestimating the time required to implement things or that the programmers aren't doing their job. Don't allocate time on a programming task based on how long it should take unless the task is so simple that there can't be any unexpected problems with it.

If the delays are caused by the programmers not doing their job rather than being caused by unexpected problems (or expected problems that are harder than expected to solve) you need to motivate them or replace them, Nypyren also makes some good points worth looking at. (Allthough i'd say that design changes are inevitable aswell and they are something you should take into account when planning a project)

I would have a talk with the programming manager, the chief technical officer, whatever his title is. I'd discuss the problem with him and figure out a plan.

There's an old saw that says when somebody gives you a time estimate, to double it and up it by a time measurement unit. So if he says two days, figure four weeks. If he says one month, figure two years. Clearly that old saw is way off. But if you're two weeks late six weeks in, you know you can add thirty-three percent to any estimated time and reasonably expect to be right, on average.

You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.

Thank you guys.

Don't allocate time on a programming task based on how long it should take

By this you mean do something like Tom Sloper said? (if they say "2 hours" double it and multiply it by some number?) Or how ?

You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.

Thats a good observation.
Any ideas to incentivize early completions?

(Sometimes) Give people Friday off if they finish early.

[quote name='Tom Sloper' timestamp='1335209083' post='4934208']
You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.

Thats a good observation.
Any ideas to incentivize early completions?
[/quote]

Simple public attaboys can go a long way. "And this week the on-time attaboy goes to Zack Zilch! Attaboy Zack!"

There can also be a toy or badge that goes to the current week's recipient, like a Flat Stanley that each recipient writes his name on as it passes through his possession before circulating to the next, or you buy a new D&D figurine each week, and see who collects the most figurines. A lot of pride can attach to very cheap little things.

Thank you.
Great ideas!

First off I want to say: Do not cut up user stories! I have seen this advice all over the place, but it is ill advised and comes from the Watterfall model. The falcy is that if you can't estimate one big task propertly then maybe you can estimate a five small tasks properly. The underlying though is that errors will even out (Law of Lage Numbers), but that is not true, small tasks have a bias towards underestimating and this results in an overall underestimation. And finally the entiere idea if a user story is that it describes one chunk of usefull functionality for the "user". If you chop them up you don't deliver that functionality until all bits are done. But now that they are choped up you stop seeing which user stories go together and you end up making the user whait longer and longer on the needed features.

Back to the topic at hand. If you are starting to catch up so much delay this early, then probably your estimates suck. You have tow options either you start to use a estimated to real time function to correct the error. This is what they do with XP, you estimate in ideal time and then convert that into real time for planing. Take your current factor and apply that to all additional estimates. A different aproach is the poject velocity, you take the number of estimated man hours you where able to do this sprint, this is the base line for the next sprint. From this you can interpolate when your expect what feature to be done. These two metrics will change over time and often improve, since you often overlook mundane tasks that need to be done.

Also if your estimates suck, you might want to look into planing poker. I think programming is the hardest to estimate task, since each problem is a new one. Although planing poker is not very acurate, but it takes into account that estimating is basically guessing and on average the result is quite solid.

Programmers are a odd bunch, I know I am one and strongly suffer from the student problem. The student problem is, no matter how much time you give him for an essay, he will use up all the time. Many programmers want to make "the right thing", which unfortunatly often leads to overengineering a problem. Ask them how they would solve the problem in half the time. I have good experiance in pushing developers to do things in shorter times and then let them refactor the bunch into a properly formed application. Just time box each step and make the programmers comit to the timebox. Honestly I found it gives better results if you give them a fixed time and variable feature set than a fixed feature set and variable time. The odd thing is they are better at maximising (more featuers) than minimaising (less time per feature).

1. Increasing time.
2. Reducing requirement.
3. Looking for more hands.

Those are only solutions we can do.

When we say "behind schedule", it usually means there exist a due, or dead line, no matter where it comes from.

That may block the way of solution 1, or it will be the best solution, to "complete" your game. Poor game usually behave poor in market.

On other viewpoint, if your dead line comes from market, that means your product may only have chance at correct release time, choose solution 2 to match the trend of market. We still can improve(patch) bad product after right time, but we can not promote the right product at wrong time.

The 3rd solution is a myth. It only works under management with discipline. However, if you have a good management, you barely delay.