“1,2,3 – show your cards.” You might be thinking, this sounds a lot like a dealer commanding a group of texas hold’em players through a cloud of smoke at a local casino, or a group of couples playing Codenames at their Saturday game night.

It’s a Product Manager leading a software engineering team through a sprint planning and estimation meeting, where a cohort of engineers are getting in their bi-weekly gambling fix of planning poker. After digging through, grooming and ultimately putting together a group of stories and tasks that will be worked on in the upcoming sprint, it’s time to estimate to see how long it will take to finish everything.

Engineer 1: I think it’s a 5, given the amount of complexity around building a new API in JSON, instead of XML.
Engineer 2: I did that awhile back in one day, and it wasn’t that hard. That’s why I chose a 3.
Product Manager: Anyone else care to jump in or have anything else to say?
Engineer 3: Let’s just go with a 3, and see what happens later.

After that meeting, the team embarks on their two-week sprint, ready to tackle a group of stories and tasks they accepted. Meanwhile, the team’s Agile Coach fires up her spreadsheet, inputs the estimations into her excel model (with some piecemeal data that was exported from Jira), trying to hedge when she thinks the team will finish. In two hours, she has her weekly project update meeting with the CTO and CPO, to share the project status, and whether the team will hit their tight deadline or not. Turns out the team is behind their schedule, which seems to be a recurring theme for many of their projects.

Software development as a whole still looks a lot like this scene. It’s a battlefield that’s built on the backs of inaccurate human estimations, which are hard to get right and based on intuition and groupthink. Spreadsheets are still running the streets like Denzel in Training Day, and are extremely tedious, take hours to update, and don’t reflect the real-time status of a software project. The average Product Manager, Agile Coach or Engineering Manager is spending at least 20% of her time on collecting, correlating and analyzing team data. If you were a fly on the wall in the halls of many organizations, you’ll hear things like, “Before our stakeholder meeting, I’ll need to block off half a day to update our project Gantt chart,” or “we’ll just ballpark in a spreadsheet when we think stuff will get done, and then decide in a meeting whether to pursue a project or not.”

There’s also other common approaches such as the quintessential burndown chart, that only tells part of the story. Teams will sit in a retrospective and look at a burndown chart – “We said we were going to do 30 story points, but we only did 15.” Great. What did you learn from that? What sort of improvement can you make? Teams just continue to the next sprint and the cycle continues.

In the next post, we’ll cover why advanced analytics is poised to help software engineering teams up their game, and better their odds at delivering amazing products, on schedule.

You may also like...

Why running a healthy CI/CD system is vital for every engineering team
Learn more
Using data to improve software engineering outcomes
Learn more

Ready to reduce your schedule slippages?

Sign up for free. Get started in minutes.

Get a free trial

We're on a mission to help engineering teams eliminate project delays and be more responsive to their customers.

©Kiro 2020. All rights reserved.

Get development best practices

Cheers! Thanks for joining the community!
Pop in a valid email address.