Ok, some confession first: This is a rather spontaneous blog post … story points … it is somehow funny how in the past few days the discussion about story points have been accumulating in totally different occurrences for me. And the following simply needs to get out of my brain, so please be forgiving with me :-).
Story Points are meant to be used for – well – stories, not improvements, not tasks and for sure not for bugs! Really, I like using story points a lot and I think they are great to bring clarity in estimations and also to judge how well a project is progressing. Sometimes things can even get painfully clear though. But we simply betray ourselves if we are putting story points just on everything. Stories for me are features of the software that have a value for the user of that system. Design changes or fixing design flaws is definitely not a story but a task or improvement. Same goes with changing the version control system or setting up a CI environment to just name a few. And for sure we should not get rewarded (with story points) for having bugs in the software in the first place. Puh!
But it is so convenient using story points just for everything and how else then can I include tasks and bugs in my planning!? First of all I personally would not even know how to estimate story points on these things as they simply not fit. Typically stories are written all for a set of requirements that share common aspects (a common problem domain) and thus complexity can be compared. How can I relate that to work on a CI system or making changes to my software design? Simple answer: By thinking in effort instead of story points and thus breaking the whole story point idea by relating story points directly to effort. Why should we do that? Why not just use the right method for the right type of work and thus estimate stories in complexity and story points and tasks, improvements and bugs in effort aka hours. Then in a sprint that contains lots of non-story work the amount of time left for stories is simply shorter. Period! And it also gets visible immediately that there might be a problem as the velocity is decreasing in such cases.
We have implemented already that story – you remember – that was similar to this one we are estimating. Let’s therefore estimate lower, it will be less work! No, no, no, we are estimating complexity and not effort. And things are not more or less complex just because other parts of the system are done already. While I can totally agree that it might be less effort … or maybe more if things are implemented badly and generalizations will require lots of refactoring work? But it does not matter anyway! But should we estimate then as if nothing is there? Yes, exactly that! And why not? It does simply not change the complexity for what I take for that. (And yes, I know that it can very hard to not let yourself influence too heavily from technical aspects.) Let’s assume we are integrating telecommunication equipment data into our system. System A sends well-formed XML while system B is sending a proprietary binary format. Well, I would say integrating B is more complex than integrating A. And of course this includes thinking of the fact that we will have a library for parsing XML, but it is independent from whether or not we have used that library already in other parts of our system. Integrating a third party system that nobody knows is estimated higher than a system we know all interfaces by heart. But again, this has nothing to do with our code base.
I could go on thinking of examples until the end of the day, but let’s look at (complexity) of involved algorithms, database actions, frontend visualization, is printing required, do we need to integrate with other (more or less complex) systems and so on. And of course we like to add doubt to our estimates, which means we are not understanding the story either technically or content-wise or we are depending on 3rd party “something” that is unknown. Basically all of this is bad as we are only postponing realising the costs of that story and yes, nevertheless it is happening. Anyway, at least try to make really good use of your reference story, otherwise all these estimates might end up quite erratic. (Even more erratic than they are anyway ;-)!) And if you want to base your estimates on some technical prerequisites – for example a specific framework that is used – note this down somewhere.
This point has so many more aspects to it I need to note down a few more:
- If you would base your story points on what is there already how do you estimate similar stories (that have no fixed order) in advance?
- Probably velocity would constantly decline, as stories would be estimated lower and lower over time.
- Whenever there is a major implementation step done there would be the need to re-estimate all “affected” stories.
How do I see the “typical” development of story points in a “working” team? Only very few story points in the beginning as working on stories is mixed with basic design work and setting up infrastructure we think will help us gain velocity later on. Then a better understanding on the problem domain is gained and technical prerequisites are done, thus more story points are burned. Maybe some pressure to keep an important milestone and thus lots of story points, but also a lot of technical debt. Thus later on a decrease in story points again as we need to work on that design issues. Now again a solid amount of story points as we have the software right and a good understanding on the problem domain. And so on, and so on … The point is: There will also be ups and downs which might make it hard to judge a projects progress on story points alone. But for sure it is one building block for judging progress.
The more story points a story has the more value the corresponding feature has for the customer and vice versa. No! And that is IMHO one of the reasons the backlog should be estimated to quite some extend well in advance. This gives the product owner a much better chance to judge whether or not a feature is worth making it to a sprint or not. And yes, there might be cases where we re-estimate stories, but then again not because of things we have implemented, but because of a better understanding of the complexity of things. That is a huge difference!
Ok, I am almost finished 🙂 … but estimation meetings. They can be a great source to really gain a common understanding on the features. And a common understanding should also lead to similar estimations in story points in a team (after some time at least). You basically discuss and re-estimate until there is only a difference of “one” (5 vs. 8 or 8 vs. 13 for example). Which brings me to another thing one need to recall every now and then: Why are we using fibonacci numbers? Because the more complex things get the harder it is to estimate it precisely. The difference is getting bigger and bigger, so at some point it is not only a question of “A is more complex than B”, but “A is really an awful lot more complex than B”. And when estimating then just go for the majorities if the difference is only one number and take the higher number if there is a tie. Or use any other fixed rule, but have one and write it down so there is not the need to discuss this too often ;-).
Finally: All this might lead to a “story point inflation” as our software basis and understanding of the problem domain is getting better and better! Yes, maybe, but just be sure you are not collecting technical debt at the same time and you are about to drop again quite a lot in velocity later on. And if in the end this is really the case I personally would not see a problem in adjusting – or choosing a new – reference story to adjust my complexity level in a long running project. Of course this must be communicated then to everyone involved as values from before and after this would not be comparable anymore!
Puh, it is getting late and I am getting tired ;-). This post is fun and serious at the same time and hopefully you can take away something from it and if it is only to think again about your estimation meetings and your way of using story points. Maybe everything is fine and maybe it needs some adjustment to ensure there is really a common understanding on this in the team.
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.