There’s a lot of debate about whether the use of story points or ideal days should prevail in Agile planning. While there are certainly benefits to both, they both also have their downsides. Read about story points and ideal days, as well as the advantages and disadvantages to each below, and let us know if you agree as to which of the two is optimal in Agile planning.
Story Points: What are they?
In short, story points are measurement units that help estimate the amount of effort needed to develop a feature. Each story point is assigned a relative value, and these values together give the size of the user story. Once you divide the size of the user story by the team’s velocity, you know the number of iterations this particular project will take. You can take the number of iterations, and the number of weeks a normal iteration takes, to determine the relative length of a project. Story points, therefore, allow you to do more than just estimate the length of the project as with more traditional methods. You can actually calculate it.
If you’re interested in learning more about story points, and their assignment, check out this blog post.
Ideal Days: What are they?
When you head into the office, there are a million things you have to do outside of the project you’re working on – there are emails to respond to, meetings to attend, and questions to answer. The length of time it would take you to finish a project, if you didn’t have to worry about all of these additional things, are ideal days.
An estimate in ideal days assumes that you’re working on the project alone. For example, if working on a particular aspect of the project would take you 40 hours, you would say that it would take you five ideal days. It’s important to remember that ideal days are not the same as elapsed, or real, days. If you have to dedicate two hours of your day to outside projects, the real amount of time it would take you to work on your part is closer to seven real days.
When determining how long it will take a user story to be completed, each team member gives the number of ideal days it will take them, and the days are added together. This is the length of time it will take your team to complete a project.
Story Point Advantages:
1. Story points play to the strengths of humans. In general, human beings are bad at estimating absolute values, but are much stronger when looking at relative values. For example, if you take someone who knows nothing about sailing, and ask them to guess the price of a boat in the harbor, their answer will likely be way off. If you point at two sailboats and ask them which one costs more, they will likely be correct.
Leaving the harbor and getting back to the technical field, story points allow programmers to focus on relative values – as a piece of work is being assigned points it is compared to other pieces of work that already have a point value. The relative comparison between pieces of work allows for a more accurate estimation.
2. When you’re trying to determine the number of story points a project has, high-level discussions between all specialties occurs. All parts of the team come together and discuss the details of the project in order to give that single number. This kind of discussion fosters collaboration and a team atmosphere.
3. Story points account for differences in team experience, as they are measurements of size. The size of what they’re working on doesn’t change with changes in the team’s project proficiency.
4. Story points are abstract, as they are measurements of relative size. As a result, managers or outside stakeholders have a difficult time confusing them with a timed reality. This in turn allows team members to estimate the project more accurately, as it is a size that can’t be complicated by outside pressures.
5. While the amount of time it will take you to finish a certain task can differ from technologist to technologist, the size of this task is the same to Lisa as it is to you. By estimating in size, you can ignore the variations of team members’ productivity.
Story Point Disadvantages:
1. If your team is new to story points, they may not feel comfortable estimating projects this way. Though most teams pick up on the method fairly easily, the comfort level with, and amount of resistance to story points may make the first couple of hours go less smoothly.
2. When teams are being pushed to get more accomplished, even when they are working at near maximum capacity, they may start inflating story points. For example, something that should be a 2 suddenly becomes a 4. This makes it appear as if they are going faster, and fosters an environment of deceit.
3. Though the relative nature of story points makes it hard for managers to confuse story points with a timed reality, it is also difficult to understand what a story point is in general.
Without a technical background, they may question why team one is able to perform x story points, while team 2 is able to perform y story points. By not understanding that you can’t compare two separate team’s story points, a manager may mistakenly punish one team for not being as ‘productive’ as the other.
Ideal Days Advantages:
1. Managers and outside stakeholders have a better idea of ideal days than story points. As a higher rate of communication and understanding between all involved in the project allows, statistically, for a higher success rate, ideal days may make the project less likely to fail.
2. At first, teams may not be comfortable with estimating in story points. Ideal days are more intuitive, and, as a result, may make the team more comfortable with project scope estimation.
Ideal Days Disadvantages:
1. Each part of the team estimates how long their ‘part’ of the project will take, and the estimates are added together. This kind of estimating doesn’t allow for team members to talk and truly collaborate on the project, which fosters a sense of individuality and not that of teamwork.
2. When estimating in ideal days, teams often forget to take into consideration the team’s experience with the project or specific technologies. A project that takes them five ideal days now, may not take them five ideal days down the line, once they are more comfortable with the project. It would take them less effort, and the estimate of ideal days will become inaccurate.
3. When you hear days, you automatically think of the 9 – 5 workday. Oftentimes, managers or outside stakeholders have a hard time grasping why a project that should take you 20 ideal days to complete will take your team closer to 40 real days.
4. Not everyone has the same ideal day. Bob may be able to finish this project in ten ideal days, while it would only take you five. Everyone has a different level of productivity, and this complicates the ideal days calculation. You could pick Bob’s 10 days for the estimate, but if you end up picking up that part of the project instead, you’ll be early. That would make your manager happy, but if it takes you five days longer, you’ll be in trouble.
5. People are often uncomfortable giving a time based estimate, because they are aware that issues may crop up. As a result, they may over-estimate the time needed to successfully finish a project.
Choosing a Side in the Debate
While both story points and ideal days have their strengths and weaknesses, we believe story points to be the better choice of the two. Story points are a relative measurement of size, and are therefore a more effective measure of the project. In addition, story points account for individual differences in productivity, take pressure off of the estimation process, and foster a team environment. While ideal days do make communication and estimation more comfortable, it doesn’t ultimately make up for the benefits of story points.
What about you? What’s your personal preference? Story points or ideal days? Let us know in the comments section, or join the conversation on Facebook, Twitter, or LinkedIn.
Looking for more information like this? Check out other blog posts on this topic by clicking on the buttons below:
Thanks to Micah Sittig and krossbow for the use of their respective photographs. Information gathered from Mike Cohn’s book, “Agile Estimating and Planning,” 2006.