If you’ve ever had the pleasure of sprint planning, agile project management, or leading a tech team in any capacity, you’ll be familiar with the mystery of getting accurate estimates out of your team members.
Even for the most seasoned senior developer, estimating is hard. Once you actually clear your plate, get the tools out, and start working on the problem - any sense of the original plan and timeline seem to go out the window. It’s really fun to put on your headphones and just sink into the deep work of making something amazing. As a product manager you need to make meaningful plans, you need to know what’s required to complete the goal, and that’s hard when the reality is “we’ll find out how long this will take once we start working on it.”
Agile project management and sprint planning emerged in the early aughts. The agile manifesto touches on several great points that help make more useful software faster. One key idea is to avoid huge time periods of no communication while something is built to firm requirements. Back in the 90’s we would take months to document business needs and mockup what an application should look like and do, and then under the waterfall project management method large tech teams would be given months or more to build the original vision. This type of “black box” process rarely delivers amazing results. There’s no chance to revise requirements as ideas are tested, and catching any miscommunication only happens when a final due date is hit and there’s no chance to correct course.
For a sense of scale, in the dot-com days of the 90’s I once worked on an ecommerce project where 2,000 hours were billed by a tech team that proclaimed themselves “done!” only for us to discover there was literally no way to check out from the shopping cart they built. Our requirements weren’t clear, and no one ever bothered to ask during the 2,000 hours of work. This doesn’t mean those engineers were terrible, nor does it mean the architecture was trash, it means we weren’t communicating very well - and life is all about communication.
So now we live in a world where “agile” as a buzzword is the norm. Claiming that buzzword doesn't magically mean you’re communicating scope of effort on work well. As a product owner managing agile teams, how do you do agile estimating in a way that helps you and your team have measurable goals you consistently beat?
User Stories
If you’ve got a clear marketing plan you likely have some user personas that represent the various stakeholders using your software. As a good product manager you’re certainly welcome to have a vision for what your software should do and look like, but instead of just starting to wireframe ideas you should start a step back with why a feature needs to exist.
By writing a one sentence story of who is trying to do what, you help make it clear to anyone involved what the actual goal is. You don’t need an ecommerce site with no checkout. You need “a way for Bob to buy boots online and get them delivered to his door.” Writing good user stories is harder than it sounds.
As you write user stories, look for them to be nice bite sized ideas. My description of an entire ecommerce platform with one sentence is nice, but it’s dangerous. The next step there would be to break that big story up into smaller ones.
“Bob can search all the available boots.”
“Bob can pick which size of boot he needs.”
“Bob can pick which color of boot he wants.”
As you break these stories down into more bite sized chunks you’ll start to discover the gotchas involved with anything complex. For example, are all boots available in all sizes and colors? If not, let's write some more stories around how site managers are going to control what is offered.
User stories deserve their own blog posts as there’s a lot you can do here. In the interests of brevity I don’t want to digress too far here, but suffice to say if you’re having trouble meeting deadlines and getting accurate estimates out of your engineers, it’s quite likely your user stories are too vague or grand. User stories need to be clear, and from then you generate smaller features and tasks that can be assigned to individuals to get done against some believable estimate of time.
Hour Estimates
So for years at PortlandLabs we thought in terms of hours. “How many hours do you think it will take to build X..” was a question we’d ask at the end of every big white board session. I can’t tell you we never had particularly accurate results, but we did figure out an early version of planning poker on our own. We’d all review some feature idea and then I’d ask everyone at the meeting to hold out fingers behind their back for how many hours, days, weeks we thought the effort required. Once everyone had made their private guess, we’d reveal our hands to the group. It was like playing rock-paper-scissors with the next 3 months of your life. If everyone came back with the same number, it’d be a miracle and quite possibly true. Often the disparity was pretty wide, and the extent of my planning magic typically amounted to just taking the biggest number from all the guesses, doubling it, and hoping we beat that.
Why was it so hard to be accurate this way? Engineers are smart, why can’t they estimate time accurately? The truth is after a certain scale, the question isn’t fair. Sure a sandwich artist at Subway can tell you how long it will take to make a turkey sub, but ask them how long it will take to invent a new sandwich customers love. There’s too many variables and so the human mind just starts taking stabs in the dark. A full day? A couple of weeks? A month or two? Any could be accurate and you start playing politics and personalities more than basing your estimate on any science.
Story Point Estimates
Instead of thinking about hours, consider using story points for your team. Story points are just a sequence of numbers we use to represent the scale of effort in something. They might be based on the fibonacci sequence, or just doubling, but as a unit of measure they get big fast. The core idea is it’s pretty easy for me to guess what I can get done in an hour, but it gets less dramatically less clear how much can happen in a day, a week, a month and so on.
Every shop that uses story points will have their own take on them, so let me just share how we use them here at PortlandLabs in 2022. (I expect it will change over time, as it’s changed before.)
1 story point - This task is easy and obvious, it will take more time for me to get into the development environment and test and deploy it than it will to ‘do the work.’ 1’s are things like “change the label on this form element.” There’s no discovery left within the task, the whole thing is going to take an hour or less.
No task is ever less than 1 story point! Sure you might think that it’s going to take 15 minutes, so you might assume that’s .25 of a story point. Is it though? How much time did it take you to stop what you were doing before and focus on this new problem? When you finished, did you go update Jira with your task? Were there comments involved? It’s tempting to think things should take less time than they do, and I want to run systems where people can feel successful. If you can bang out three simple tasks that all have 1 story point inside of an hour and feel like a rockstar, as a product manager, we’re both winning. ;)
2 story points - This task is clear, doable, and shouldn't take more than a single work session, but it does involve some real work. To me that means you’re going to need to not be disturbed and it might take you the better part of one deep work session. If you haven't read Deep Work, you should. The underlying premise here is it’s hard to get in a real flow state and you will be lucky to get 2-3 flow states going in a productive day. “Hey go through our marketing site and make sure every form has this privacy protection statement” is 2 story points. I don’t know how many forms there are, and it’s quite likely other improvement opportunities will emerge as that resource goes through every form. If they get this done in an hour, more power to them, if it takes all morning - I wouldn’t be shocked.
4 story points - This task is not 100% clear yet. It looks believable, but there’s still some unknowns in how you’ll approach it or what the final solution will be. That said, as a resource you believe if you spend a whole day on it, you should be able to get it done. “Prototype Stripe’s built in commission structure to compute marketplace payouts for our 3rd party vendors” is a 4 point task for a senior engineer here. Note I’m not asking to have it launched, I’m asking to have fully explored its functionality and have a clear vision for what needs to be done to use it. Likely new tasks with new story points will emerge as sub-tasks or new user stories when people are working on 4s. A value of 4 story points is roughly an uninterrupted day.
8 story points - This is the recognition that once you get beyond a full focused day of work, it’s hard to really know. If we agree a task has 8 story points, that probably means it’s going to get a bunch of subtasks before we expect anyone to be good about delivering it on time. Sure, maybe it really is 2 days of work, but it could just as easily be a week if things go poorly.
Beyond that, we don’t pretend to know. If you’re building a project plan and every task on there is 2 weeks or more, you’re playing pretty fast and lose. Perhaps you’ll beat those numbers, and maybe you’re just being conservative with your promises and that’s great, but I would expect a pretty high variance when you go back and look at total time spent once everything is actually done.
The nice thing about story points is as a manager it gives you numbers you can use in different ways. I can look at a project plan, see it’s entirely 1’s and 2’s, and think we have a high level of confidence for the approach vs one filled with 4’s and 8’s. I can look at a specific resource and measure their “point velocity” or how many story points they average completing in a week. I can look at tasks created in Jira that DON’T have story points assigned and question if expectations are being properly communicated.
It’s certainly not magic, and the truth is we still do have big tasks where it’s just “i dunno man, spend a few days trying to figure that out.” That said, I can say when we use it well, it creates a much clearer picture of what’s going on and we make estimates that are closer to how long things actually take.