Well, we still need you to provide a detailed task breakdown and hourly estimate for each task so if you can do that before starting work on your story backlog, that would be terrific.
We have a new trick too, every task in the backlog is estimated as 1 day worth of work. Most of the times those tasks take 3-4 days tops,
Even when we say otherwise, they still force the 1 day story rule...
Sometimes you can. At some point I worked as a consultant assisting a team that actually picked the next item from the backlog as their next task. All tasks were estimated before they were put in the backlog and assigned to someone. I would usually finish tasks in less than 30% of the esimated time, while some would use 3x+ the estimated time, and then only because they were receiving assistance a couple of hours per week.
The guy doing the estimages was evaluated based on his ability to estimate accurately, so he had to inflate the estimates beyond what would be reasonable.
This was in a country with really good job protection laws....
A lot of good suggestions in this thread, I am left with one question that I haven't seen asked yet, where are story/time estimations in this? Someone working on a 1 point task for an entire week should be a metric that your boss can do something with. This together with highly specific written out stories like someone else suggested should at least remove a lot of unneeded discussion
Other than that, maybe set a time limit of a few months for yourself, if you haven't been able to improve things, it's time to move on.
Discussing about the effort required for each task/story, is crucial to generate alignment within a team, determine better the scope of a task/story -- and decompose it, if it appears that the effort would be so big that tracking what has been done and what remains to be done would be intractable.
The by-product of these discussion may be summed up as a number. But oh yes its unit must not be time.
If it's not something you can scope out when the task is brought up, you can specify how much time it would take you to research it in more detail to get an estimate.
Need to include "tasks which will take significant time but I can't tell you what they are because we won't know until we get there". Managers can't seem to deal with the notion that 10-30% of a project is completely unknown when writing initial schedules.
I'd disagree. You tell an employer you're going to spend 480 hours on a project. You have far more responsibilities than just that project. A month later it is perfectly reasonable for them to ask how many hours you've invested, and what the remaining timeline looks like. I'd love to be able to automate this process.
Don’t you still have to correctly estimate the amount of work (time) to complete each task in your backlog?
You can apply all the “science” you want, but at the bottom of it all you have engineers holding up a card with a “4” on it when the scrum dude says “add date picker to the Foo widget.”
Does your team do estimates in advance for how long a task should take or is it cowboy coding just creating random features the customer might want? If you have estimates, do you overshoot them or what is it that quantifies you as being slow? I would recommend breaking tasks down and giving each task an estimate that you should try to follow, with clearer goals and clearer deadlines its much easier to keep on track, the unit for estimating should be nr of days, not hours or minutes.
I agree, but I'd say story points are themselves a mistake. In the end, what matters is time. Story points don't matter if the schedule slips. So you either get story points and no way to keep a schedule, or story points + time estimates (with useless story points), or just go with time estimates.
The schedule may still slip, since estimating time is very difficult, but at least some of the time it will be correct (or estimates will get padded until things happen on time). Either way, it's more useful than giving up on the problem.
> For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date.
Until it turns out that the remaining 15% takes half of the total time. In my experience, estimating about 80-90% of a project accurately isn't that difficult; it's the other 10-20% that can end up taking considerably longer than you expected and throwing off the entire estimate.
Mgr could not say it directly, but he implied that timesheet must have 40 hours reported on the main project.
How hard could that be to write it down like that?
I understand that it's still unpleasant to deal with that.
If you’ve done the task before, double the estimate. If you’ve never done it before, 10x the estimate. Break tasks down to granularity of 1-8 hours. No more than that. Estimate time != real time because life, meetings, other projects.
reply