Welcome to “Agile” the methodology where everything’s made up and the points don’t matter

Story points are a common practice in agile planning and in this article I wanted to talk about some of the theory and my personal experience with pointing. I’m going to assume that all readers are aware of what story points are. But, if you’re not, take a quick peek at the wikipedia article.

I wish I could write more about the history of story points but I’m strugging to find information on that. I heard a rumor that a famous consultant was sick of being asked for deadlines so they came up with idea of points instead. Because the points don’t directly relate to units of time, it drove the concept home that these estimates are just estimates.

Whether or not this is historically accurate, it still explains why you should avoid estimating with units of time. Here’s a case study where a team tried to estimate in hours instead of points:

With hours, we measure our progress and declare something like “we’re doing 22 hours per week”. This can annoy (why aren’t we going faster?), confuse (wait, is this in actual hours or ideal hours?) or even anger (this is a team of slackers!). But a statement like “we’re doing 22 points per week” doesn’t generate these same emotions. It may elicit initial confusion (what’s a point?), but that’s just an opportunity to explain what’s really going on.

Even though points don’t directly relate to time, they can still be used for projections by a Product Manager. If you know the average number of points the team completes per iteration you can leverage this to project when milestones will be reached.

But points aren’t just a compromise to giving specific deadlines. The act of pointing stories is a useful process to the development team. For example, if I think a story is really simple and easy and I say it’s a 1 but my peer says it’s a 5, that means there’s some disconnect that needs to be ironed out. Without story pointing, this disconnect is never discovered. This creates situations where a developer says, “I’ll have it by lunch” but it takes 2 weeks. Or, “This is so hard I think we should consider if the effort is worth it” and the story ends up taking a day.

Paradoxically, story pointing can be used to keep meetings short. If you calculate the average points you complete per iteration and in a pointing meeting you’ve already pointed 2x that average, you know you can end the meeting early: It’s highly unlikely that you’ll be able to get through the work you’ve already pointed so there’s no point in staying in the meeting.

Slight tangent: Sometimes Product Managers like to point as many stories as possible because they think it gives them better projections. In practice I see the opposite being true because once you get two weeks out the points stop being based on reality. Stories start to depend on other stories being completed first. The prerequisite stories can effect the level of effort on future stories in ways you can’t predict. In my opinion, I don’t see a lot of value in pointing more than 2 weeks in the future.

Lets assume that after that 1 vs 5 point discussion, we agree that the story is a 5 pointer and that 5 points is very high. How can that be interpreted and leveraged? Well when a story is pointed very high that usually means there’s a lot of uncertainty in it. Sometimes that means the requirements aren’t clear and the story needs to be rewritten. Sometimes that means the team has no idea how to implement the story and it will be a research task.

Be wary of working on high point stories. They often take much longer than anyone could have anticipated. It should send the message that even though this will be started this iteration, it may not be finished this iteration.

I wanted to end this article by mentioning that there is a “No Estimates” Movement. My interpretation of this is every story is 1 point. I have to admit the concept is appealing when I put my developer hat on. But when I put my Product Manager hat on, the idea doesn’t seem very appealing. I’ve yet to experiment with “No Estimates” so I don’t know how it would play out in practice.

I hope this article helped you think of story points in a way you hadn’t thought of before. If you have a different perspective, please let me know via a comment to this article.

Join the email list for bonus content.

13 thoughts on “Welcome to “Agile” the methodology where everything’s made up and the points don’t matter

      • alanz says:

        The original extreme programmers documented their process on that wiki. So however it turned out after, I am pretty sure that is where it started.

        Note: extreme programming was renamed agile somewhere along the way

  1. Victor says:

    Hey, nice post!
    However, when you say you can end the meeting early because “you’ve already pointed 2x that average”, isn’t this counterintuitive in a way that you should calculate the RoI to figure out which stories you’ll take on this sprint?

    • Daniel Kaplan says:

      Hi Victor,

      The way I see it, if the level of effort affects your prioritization, you don’t know what your priorities are. You’re just putting “nice to haves” at the top and you don’t really know what you *need*.

      RoI is an interesting point to make. Assuming your stories fit within an iteration and that iteration is small, if you wonder if the difference between 2 days of effort and 4 days of effort will give you good RoI, there’s something wrong about RoI you expect to make. Throw that story out and work on something you suspect could give you a crazy RoI even if the dev estimate is high.

  2. Thomas says:

    My development team has been doing the “No Estimates” for just under a year now without any negative impact.

    My motivation came after I sat in this talk at Agile 2015 (this is just an interview with the speaker):
    https://www.youtube.com/watch?v=BGgqyv55iRQ

    He shows how not estimating doesn’t mean not projecting, and talked about how to project using probability.

    We plan according to the average number of stories we finish per iteration (2 weeks for us) and don’t worry about anything other than priority. We’ve basically merged estimation/prioritization/planning into one meeting where stories are prioritized and, if necessary, broken into smaller more easier to deliver stories. This had an unintended benefit of getting all of the stakeholders/developers together

    It’s worked really well. It did take some convincing of our more business oriented team members (I’m one of the developers), but after a few months of actually doing it they started to see the benefits.

    It might not work for everyone (I believe we’re the only team at my company trying it), but it does for us.

    • Daniel Kaplan says:

      Hi Thomas,

      That’s a great story. I have a question: How do you decide when a story should be broken down? Is it an informal gut check?

      Also, how do you deal with deadlines?

      Thanks

      • Thomas says:

        We break up stories when the individual requirements can be delivered independently. The trick, obviously, is being able to recognize that. That part is more experience and understanding of our various systems.

        Often our deadlines are artificial, but when they do come up they are handled in the priority phase.

        Since we know roughly how many stories per iteration we can do, if we have a rough idea of the number of stories that need to be completed we can either project out for a rough timeline or count back form a set date to decide on feature priority.

  3. Michael says:

    Story Points are prices. You cannot measure using money.

    The result of story points converted to hours is used in risk models. If you don’t use risk models forget about hours.

    Think of a market-stand where the supplier hands over one lolly after the other to the developers and says, ‘How much money do you offer in return’ – many lollies in different shapes.

    As a result from this the Scrum for example cannot scale beyond on market-stand since the classical free market price is a local one.

    After the ‘Decline and fall of the American programmer’ programming was reintroduced pimped up and disguised in a bunch of methodologies. After having realized that this brillant disguise turned out to be ‘The Emperor’s New Clothes’ once again the project managers took over control and especially business tried to manage software development.

    For a short period things did not work out that bad since project management introduced once, especially the first time and the second, lead to better results. Afterwards successful projects teams broke apart, … there are many factors influencing the outcome.

    All of sudden also project management did not ship appropriate results anymore. Since managers are never wrong the blame for the failure has been put on anyone else and finally on anything.

    In a next step projects managers started to sell parts of the ‘piece list’ to experienced developers, who smelled a rat pretty quickly…

    Agile methodologies address parts of the criticism applied. That’s the great opportunity that does come with agile.

    In general all estimates suffer from very much the same problem. Even data-point estimates or function point estimates relied on several screws to tighten the estimates (internal performance screw). Estimates tend to work ‘fine’ for projects whose scope is a large one.

    Given an extreme example. SAP BW (Mixture of BI and data warehousing) is heavily relying on meta-data, naming and reuse. You cannot estimate how long it will take to build one cube but you can very precisely estimate that 300 cubes in such a warehouse require 4 people 2,5 years. Once you follow the naming conventions, have all the master data in place and the business knowledge involved you can click together such a cube and the staging while talking to the one who presents the business requirement on the phone in almost 10 minutes. Not saying that this practice is a good one, but the same cube takes you 3 weeks to finish in the early beginning.

    I personally think that the ‘No Estimates approach’ is a lot more fair for both sides.

    If I think of the Scrum, what makes up the success is trading in the requirements and not ‘looting’ the price for the specific lolly from the customer (developer in that case) since no one else does have an idea how long developing that specific piece of software (lolly) can take.

    The more you tighten the screws the more you tap into the most well known trap again – WISCY or WISCA. Why isn’t Sam coding (yet|anything).

    I just extracted some useful elements from Agile and added those to a pragmatic one that somehow fits in almost every situation. I am far away from being an expert on this topic. Setting up an agile process just for me would similar to conspiracy by the one from my perspective.

    If ever possible I personally use a technology that allows estimates to become more precise and shorter and shorter the closer the development moves towards ‘maintenance’. I personally call this ‘Designing for Predictability (too)’. This helps the customer later, since systems are designed to stay our jobs usually not.

  4. In this methodology, the rules are ever-changing, and the points assigned to tasks are merely symbolic. It’s a dance of continuous improvement, where collaboration and communication take center stage. Embrace the chaos, because in Agile, it’s all about progress, not perfection.

  5. In Project Management, Agile emphasizes flexibility, collaboration, and iterative development. It breaks down projects into smaller tasks called “sprints,” fostering adaptive planning and continuous improvement. While some may criticize its lack of structure, Agile thrives on embracing change, empowering teams to deliver value efficiently. So, let’s dive in and see how this improvisational approach can transform your project management game.

  6. As an avid practitioner of Agile methodologies, I must respectfully disagree with the notion that everything is made up and the points don’t matter. Agile is a powerful approach that promotes adaptability, collaboration, and iterative improvement. Through staff development and training , teams can harness Agile’s principles to drive innovation, enhance productivity, and deliver customer value with greater efficiency. Embracing Agile is a step towards embracing progress.

  7. Agile embodies the importance of flexibility and adaptability. Although it may appear uncertain, its true value lies in its capacity to grow and meet evolving requirements. By embracing the Agile mindset, we liberate ourselves from rigid frameworks, prioritizing innovation and collaboration. Let’s ensure that our efforts count by delivering value and empowering teams.

Leave a Reply to Michael Cancel reply

Your email address will not be published. Required fields are marked *