In our last two posts on using Arbor, we talked about the two crucial steps to creating user stories: writing the story itself and adding the acceptance criteria. But while the actual act of cataloging user stories is important, a big part of the Arbor’s usefulness comes from what you do with those user stories. After you’ve captured and organized your entire product backlog in user stories, Arbor lets you quickly and easily estimate the size and scope of your project. This not only gives you a handle on the cost and timeline of the project, but it also lets you prioritize what you need to get done and in what order you want to do it. We’ve got a detailed video on this subject, but this article will give you a high-level overview of using Arbor for estimation.
Estimating with Story Points
The first step to estimation is adding a point value to each of your stories. If you look at your backlog for your project, you should see a gray circle, probably with a question mark in it, to the left of each story. If you click on the user story to see its expanded view, you should still see the gray circle, and if you click on the circle, you should see a dropdown menu with a series of numbers. These numbers represent story points, which is a theoretical framework we use to estimate the amount of time and effort needed to complete the story.
Story points are laid out in a Fibonacci sequence, which is constructed by adding the previous two numbers in the list to create the next number. We use Fibonacci sequences in story points because they build an inherent “roughness” into your estimation and encourage you to think in broader terms: ultimately, any estimation is somewhat imprecise, so it’s not reasonable for you to expect to know whether a story is 20 or 21 points at the beginning of a project. The Fibonacci sequence ends up producing more reliable estimates because you’re not expecting to have a detailed knowledge of time and cost – the estimation is just for broad, imprecise calculations.
To add a point number to a story, just click the gray circle and select one from the drop-down menu. Go ahead and do this for every story in your backlog.
Estimating: How Long & How Much
Once you’ve done this, refreshing the page should show you some number in the “total points” box of the estimation window, which is located between the user story creation field and the backlog of stories. This number shows you the aggregate number of points from your combined user stories, which is also the number of points you need to complete to finish your project.
Here’s where things get interesting. Click on the gear icon to the right of the Estimation area, and you should see a box titled “Estimation Settings” with two fields: Velocity and Cost per Week. These two variables, combined with your total story points, will let you estimate the overall cost of your project and the time you need to complete it.
Velocity & Cost
Velocity is a measure of how many story points your team can complete per week. At the beginning of the project, there’s some inherent uncertainty in this number. That’s ok, though – it’s best to take a leap of fake and enter some rough estimate of your team’s velocity. As time goes on and you get further into the project, you’ll want to revisit this number and calibrate it based on your actual working velocity.
The other box, Cost per Week, is just an estimate of the cost of your team’s time each week. If you have a team of four developers working 40 hours per week and earning $50 per hour, your cost per week will be $8,000. If that same team is working only 20 hours per person, your cost per week is $4,000.
Once you input these two variables, Arbor will automatically use them to calculate the total cost of the project and the total time in weeks you’ll need to complete it. You might notice that playing with these numbers – even only subtly – can create wide variation in cost and timeline, so you’ll want to estimate them as closely as you can and continue to calibrate them throughout the process.
Prioritizing Your Backlog
The real value here isn’t just knowing the cost and timeline of the project – it’s in your ability to prioritize certain features and see how your prioritization decisions impact your launch timeline. As an example, you may decide that only 4 stories from you 20-story backlog are necessary for an initial MVP launch, but you really want to include two more that add a nice additional functionality. However, if those two extra stories are high in point value, then that extra functionality could easily add thousands of dollars to your MVP and delay the initial launch by weeks or even months. Arbor lets you see that information upfront, so you can make informed decisions about what goes into each product iteration.
Take some time to play around with your backlog, and try using different numbers for your velocity and cost per week as well as different sets of stories to see how they affect the cost and timeline of the project. We think you’ll see pretty quickly how small changes in the velocity, cost of your team, and what stories you include in the backlog can have big impacts on the total cost and time of your project – so keep all of that in mind when you’re deciding what to include in your MVP, v1.0, and subsequent updates.
Get Arbor Today
We hope you find this estimation primer helpful, and if you haven’t tried it yet, we’d highly recommend signing up for the Arbor Beta testing program. We’re always updating Arbor with new features and improvements, so keep an eye out for those, and also watch out for the full release of Arbor, which should be coming soon. This article concludes our three-part series on using Arbor, so now you should be armed with the skills and knowledge to use Arbor effectively as a product strategy tool. So go ahead and get your hands dirty with cataloging, prioritizing, and estimating your project backlog!