Why I value story pointing and how you can get more value out of imaginary numbers.

When I first encountered story pointing it was at a digital agency. In preparation for my first planning poker session I read about what it was along with how to derive time from points. The stories we were pointing that day were combined into the frontend mobile work and the backend server-side work. For this I pointed things an eight as it was easy to implement on the frontend while our backend engineer was assigning most around twenty-one. We agreed to disagree that day and no longer pointed for the remainder of the project, we still delivered on-time and everyone was happy.

Fast forward a bit and I had just finished agile training at a new job. We learned about the abstract idea of story pointing through assigning numbers to animals based on how large they were. A cat was a one, a dog a two, a deer was a three, all the way up to the elephant which was a thirteen. In practice it took my team several sprints of struggling to come to a consensus on how large stories were but around the third or fourth sprint we had very little discussion about sizes as we were all pointing stories the same way and most disagreements were settled very swiftly.

Okay so why am I sitting here giving anecdotes? Despite my one success with story pointing, I’ve mostly seen failure, and that failure is more what I want to focus on for the rest of the article. After all, what the heck do points mean when they aren’t tied to time and yet they are directly related to how much work you are delivering in 80 hour increments?

Product managers like to know when you can deliver things — Velocity

It shouldn’t come to a surprise that a product manager wants to know when they can deliver various features. Agile teams don’t commit to large volumes of work up front and instead work in smaller increments while delivering value overtime. Yet at some point in time the marketing department needs to get involved with creating material to build the hype train for that new major feature.

This is where velocity comes in. Providing that a team remains relatively consistent sprint over sprint it’s reasonable to assume their velocity should as well. If a team delivers an average of 100 points per sprint at 80% capacity (the max capacity you should plan for) then you can be reasonably sure over the next quarter they will deliver around 600 points of work.

Let’s take this a step further and say that your smallest epics come in around 50 points with the largest ones being 200 points and each epic ties into a major feature. Now your product manager can work with a bucket of points to figure out if they want to ship three major features this quarter, twelve smaller features, or something in the middle. Your product manager can now make vague commitments and everyone is happy.

Engineers (me) like having work-life balance — Capacity Planning

My least favorite thing is when I over-commit to how much work my team can complete in an 80 hour sprint. This means I need to have a good understanding of how much work the team completes on average every sprint so that I can forecast how much work we can commit to. In order to do this I need to know what our velocity is along with what our capacity was to achieve that velocity.

Going back to the previous example, our team has a velocity of 100 points given 80% capacity (the other 20% is taken up by meetings and other random distractions which just naturally happen in an office setting). Armed with that information we can do some math to realize if we were 100% focused on our work we’d deliver 125 points per sprint. Furthermore, let’s say we have a team of five engineers which gives us a bucket of 400 hours every sprint, of that 320 hours are spent on sprint commitments, which means each hour of work yields 0.3125 points.

Okay, but what does it all mean though? What happens when a holiday comes up and your team takes a few days off and the office is closed for an extended weekend? You plug in how many hours the team will be available for work, multiply it by 0.3125 and you pull in that many story points (rounding down). So keeping up with this example, if your team is available for 250 hours that sprint they can commit to 78 points of work.

Wait but points aren’t tied to hours, you’re cheating! Correct, points are not derived from hours. The amount of work I can complete in 8 hours is different from the work someone else can complete, so this is why we focus on effort in points. A one point story for myself might be half a day of work while someone just starting out could take a full day to complete or someone more experienced might tackle it before they finish their morning coffee.

Story points are just a means to an end, they take something that can’t be tied to hours (software engineering) and make it possible to estimate how much effort it might take to complete a project. While there are other ways to estimate how long it will take to complete a project, I feel when done correctly this works really well.

Thanks for taking the time to read through my article. If you found something to be not quite right or have other information to add please reach out in the comments section below. If you enjoyed this article, please click on the clap icon a few times or share it on social media (or both). Lastly, I’m starting up a mailing list that is powered by ActiveCampaign, if you want to get weekly newsletters then please use the sign-up form below.