creating a PM system and what's best way to get developers to estimate?

Question

Over at http://alvazan.com/demo, we have been thinking about a feature to get developers to estimate on time. What do PM's think of having the ability to turn on an annoyance feature that emails the developers and warns them to get their estimates and of which if you turn it on, it would keep emailing them and then start emailing them faster until the item was estimated over the course of 3 days since the item was put in the backlog/requirements.

At least that is one example. I am curious if anyone has any ideas or likes the above idea which is just one example of what we are thinking.

thoughts?

Our system is currently free for use if you register in the next 2 months by the way.

Answer 1

I am not really sure emailing until estimation is done will work. It will be explicit force on the team. Again my views :)

Instead if something can be done in following lines:

a. Tool automatically identifies who is set to complete their work and is going to have some levy or time in following 3 days then assign stories for estimation to those developers.

b. Tie that up with points system providing bonus points to members who do the estimation in time and deduct points on ones who do not. May be a points dashboard will help which is quite visible to the organizaton.

c. This points system need not just be restricted to estimation but other engagements as well where people are supposed to take initiatives within the team to close the work items like "Reviews", "Own Software Demos", "Build & Config Ownership across sprints" etc and others.

Answer 2

I don't think this requires a soft-ware solution so much as a soft-skills solution.

The best way to get team members to provide estimates in a timely manner is to make it in their best interest to do so. Get the team engaged enough to do the work you need in the timeframe you need it in.

If you have the power to provide rewards or penalties make sure they are aware of what the consequences are. If you don't have the power then get whoever does (e.g. functional group managers) on your side.

Answer 3

Developers will write estimates when it becomes easy and relevant to do so. They will not estimate just because you email them. In addition, emailing developers as individuals will be likely to result in individual estimates: made in isolation, without consulting the group, and with all the resulting anti-patterns which come from rewarding / punishing individuals.

It's also likely to get devs' backs up. At best, they'll simply filter the emails out. At worst, this will result in conversations like, "Oh, sorry, I missed the meeting invite - too busy dealing with the estimate emails."

This will make PMs / SMs happy only in the very short term, until they realize the side-effects of the feature and turn it off. Please, please don't do this.

If you want to help developers estimate, focus on letting the developers know - through broadcast, rather than through push - that a particular task needs to be estimated. This could be done with a normal card wall and a small piece of text or an icon (I'm not seeing such a card wall in your product, but that's the right place for this IMO). It needs to be optional as some teams only estimate when they pick up the story or (in the case of Kanban, for instance) use recorded data for estimation purposes instead of guessing.

Also focus on making it as easy as possible for developers to add estimates, or to read them automatically from whatever tracking tool they're using. That will help more than any number of emails. Wherever possible, assume that people want to do useful things and put your energy and creativity into making it easier for them to do so, rather than forcing them to do so through other features.

Answer 4

Why don't you just stick the entire team into a single room and play planning poker? Even if you choose to size each story using estimated effort in hours, you'd get things done. Timebox the meeting, e.g. 1 hour, and if one meeting is not enough have a session in the morning and another in the afternoon or schedule one per week. In a weekly meeting you could look at just the new stories.

You don't necessarily need the entire team. A somewhat scaled down version could be a cross-functional team, e.g. consisting of a business analyst, a test and a developer. The three need to agree on sizing.

If you have a distributed team, set up a conference call and share a desktop. Present the stories using whatever software works best for you. Then go through the stories one at a time and size them.

In my experience using email for something like this won't work. No tool will solve a problem that boils down to people and their behavior. You can change attitude only with good leadership. Only once that is in place and the processes are established (incl. estimating) tools should be introduced to support or speed up the processes.