It has come to the Senior Management’s attention that the project is going to overrun. No surprise to anyone…well, except the managers. So they want a new estimate of how long it is going to take.

The best way to get an estimate is to ask each of the teams, then add the totals together, right?

Well, not in their minds, no. What they did is take a selection of staff, and book 2 all-day meetings to go through all the teams work!

When I have doing pointing sessions in the past, we usually do them for 2 hours max, and by that point, everyone gets tired and switches off. Some discussions really drag on as you debate how complicated features are, but that’s only if you know the requirements well.

If you are dragged into a meeting to discuss work you have never considered before, this is going to take longer, or people are just going to give wild estimates because they are estimating with incomplete knowledge.

So is it a good idea to bring people in who have incomplete knowledge, and also force them to estimate work they don’t care about for several hours straight? Well, no, obviously.

From what I witnessed, half the estimation team was present for both days, with the other half having different members; which probably made it even more inefficient and inconsistent.

The breakdown was roughly as follows:

3 Product Owners

2 Software Architects

2 Lead Developer

2 from Product Team

and my favourite selection… 1 Apprentice Developer.

Welcome to the world of Software Development! Here’s an all-day meeting to estimate work you don’t understand, and will be embarrassed in front of the experienced developers when your estimates are way off the mark.

We had a meeting that involved multiple teams. At one point we went back to our desks and talked about the plan for the next Quarter. We looked at the main features, put them in order of how we wanted to tackle them. We considered the length of time they would take, and which ones could be done in parallel. The Product Owner (PO) drew up a nice Gantt chart with rectangles showing the size, and the rows showing the parallel approach.

We had an hour, but took 45 minutes, then rejoined the meeting. The PO did our presentation describing all the work items and the justification to the order. The host then asks the next team’s presenter to come up.

The main developer shakes his head, another developer looks down and plays with his phone. Their manager, who is normally really confident, speaks in a dejected tone.

“We don’t Story Point our work, so we didn’t know the size of the work. We simply didn’t have enough time to plan, so we just wrote down a few bits of work that was coming up.”

Pretty much the end of their presentation.

Here are my comments:

1. We knew about this meeting a week in advance. How come they didn’t think about their work in that time?
2. 1 hour was more than enough time to fill in the form for the presentation.
3. We hadn’t Story Pointed our work either, and we don’t have clear requirements, but we still came up with a respectable plan.
4. Despite our PO explaining what each feature on our plan was, this team made no attempt to explain what any of their work was. Surely if someone does a presentation before you, you need to make some attempt at matching the quality.

In their section of potential risks, they mention they don’t have a PO, so struggle to prioritise their work.

Here are my comments:

1. Although we have a PO, I think a lot of our prioritisation is actually driven by the development team. The PO adds the overall idea, but we tell him how feasible it is and what order it needs to be completed in.
2. Out of all the teams in the business, I think you can argue they are the team that has the lowest need for a PO, hence they haven’t hired one for them. Their requirements are driven by other internal team’s requests. They can easily decide on the priority by what they are asking for.
3. In our appraisals, we are encouraged to provide evidence of times where we have stepped up, and this situation is a prime example where you can show how organised/responsible you are. Making little attempt during a meeting, and being disorganised during your project when you have a backlog of 100 bugs/feature requests from other teams is a bit irresponsible. Surely you can judge how serious the bugs are, and how important the features are for the business. It’s not like they have no work on their board; they really do have 100+ items on there.

In Agile Development, you have a concept of Story Pointing and Team Velocity. Most people hate coming up with time estimates. If it is in hours, it is too specific, and then you feel under pressure to meet the exact timescales. With bigger work, it’s quite hard to measure things in days. The idea of Story Points is that you can just gauge items in comparison with each other, so you think about your smallest piece of work, then benchmark all other work against it.

Although teams may roughly have the same scale, and you could roughly map Points to days; the scale only truly makes sense within that team. So 5 points for Team Badger, may be a different size to 5 points by Team Snake.

The amount of Story Points you complete in a “Sprint” (often a 2 week period), becomes your Velocity. Well, the Velocity really makes sense as a moving average across multiple sprints, because in Sprint 1 you may go through 20 points, but Sprint 2 may achieve 35 points. If you analyse it, it may be because people understand the project and are working better together, so improved in the subsequent weeks.

We had a meeting today. One of the questions was

“What’s your team’s velocity? If you don’t have one – then pick a suitable number“.

A) What are we doing with these numbers? Comparing them between the 3 teams? It’s nonsensical.

B) It turns out people haven’t been working in this Agile style anyway, and haven’t Story Pointed their work. But if Velocity is a sum of completed work that has been estimated, how can you estimate how many points you have completed by estimating what you think your estimations would be?

I’m sure managers are getting dumber.