We deliver projects in fixed price, fixed time and fixed scope environment. We have a contract that specify those, specifications of features. Recently, an agile couch was trying to convince me to switch to story points but I fail to see how this would help me? Why should I add an abstract unit that does not bring anything? Velocity is nice, but I have features estimated with time so I can clearly see whether we are making the deadline or not.
By the nature of the contract, I cannot not have time estimates as high level estimates were done to calculate the price! So, I know I have 13 people, 5 months and have to deliver X features.
How would story points help me in this situation? I am really trying to see the benefit here.
-
Is this agile couch earning something in the process? Because based on your description... he'll be earning more than you if you implement agile.– Tiago CardosoCommented Jan 24, 2019 at 17:13
-
@TiagoCardoso Yea, the upper management hired him to possibly improve things but we are a large company. To be fair, we do have R&D departments where agile might work just fine (in the end, it seems designed for product development rather than solution delivery) and they have the liberty to play with scope, time and even costs. Not for us who have to honor a strict contract with the customer.– John VCommented Jan 24, 2019 at 17:40
-
1At the end of the day, the customer can also benefit from agile, so long the customer also onboard the agile train. The idea of MVP is pretty good... so instead of looking for "using story points" I'd suggest to look for other benefits agile can give you and your customer.– Tiago CardosoCommented Jan 24, 2019 at 18:10
-
1"fixed price, fixed time and fixed scope environment. We have a contract that specify those, specifications of features." How many of those projects overrun on time or budget or need de-scoped?– Venture2099Commented Jan 25, 2019 at 13:27
-
1That is not what points do. I am not arguing in favour of points. Points are a distraction. I am interested in how you get held to a project with three points of the iron triangle..fixed. I know you have customers and reality is reality. Just baffling that even in 2019 customers are still trying to adhere to this nonsense.– Venture2099Commented Jan 25, 2019 at 18:49
|
Show 3 more comments
4 Answers
You are asking a question in good faith and the truth is story points may or may not help you. Like a lot of practices and patterns within the Agile ecosystem; it depends.
Let's break your points down in order of importance.
I know I have 13 people, 5 months and have to deliver X features. How would story points help me in this situation? I am really trying to see the benefit here.
It wouldn't.
However, story points are just one aspect of a wider framework of patterns that the Agile Coach has not explained. The idea is to move from predictive modelling to adaptive modelling. If your business model cannot support that then definitely carry on with your method. There are lots of ways to optimise and improve waterfall-style predictive elements.
If you are curious about adaptive planning then the basic idea is to do a small amount of work, test it, adjust it and use the learning to inform the plan for the next part of the work. It is nothing new really; engineers and scientists have been applying the principles to lots of things.
However, because we want to use learning to inform the plan then we like to decouple time from the equation because we never quite know what we will find out. It works best for uncertain requirements or partially-certain requirements.
Enter the story-point.
Why should I add an abstract unit that does not bring anything? Velocity is nice, but I have features estimated with time so I can clearly see whether we are making the deadline or not.
As the answers have alluded to; the idea is to decouple individual time estimates because a developer is fallible. Crowd-sourcing during planning is less fallible so we use the wideband-delphi method of estimation and we use story points to measure complexity.
Your team pick a baseline story that represents the smallest unit of productive and independent work.
- If we were a web design team a 1 point story might represent the addition of a single button coded in test, deployed to non-prod and then elevated to prod.
- As a cloud infrastructure team a 1 point story might be the deployment of a simple web application, deployed to non-production using the Jenkins pipeline etc
Your team choose the baseline story and then compare all other stories to the baseline and say roughly how much more complex it is.
What does this give me?
Well, a lot.
It lets you know if the project requirements are too big, vague or unclear since very unclear stories will invariably high estimates since the developers struggle to say they are low in complexity.
It gives the team a broad average estimate for any given story and then you can roughly estimate the entire backlog by applying the average estimate to every story.
Each time you run the planning ceremony to estimate user stories your team get better and better at estimating and project estimates get much more accurate and your empirical data can be used to estimate new projects.
As a team delivering a Product, we are not interested in an individual. What we want is the average of what the team can deliver. And that is why we measure complexity. Because the work will be broadly shared around the team. So, by understanding what a team can accomplish in a timebox we can take a very accurate guess as to what a team can accomplish in 20 timeboxes. Or 52 timeboxes and thus model when the project will end.
When the project will end?
Yes, if you know what the scope is and you know how many items on the scope you accomplish you can model very accurately when the project will end. Every time something happens such as new requirements, scope changes, loss of team member, holidays etc...we can adjust the model to show what the new finish date will be without having to adjust the start to finish dates such as a gantt chart.
Story points are closely linked to the Burn-up Chart although you can burn-up using any unit of measurement, not just story points. They just go hand in hand like peanut butter and jelly. #
Are there any caveats?
Well, yes, a few.
It needs buy-in from your customers. It also benefits from having a strong BA presence to be able to author high quality user stories instead of simple line items on an MS project plan.
However, the biggest drawback is that empirical data is not available from the start and it requires a lot of goodwill to get started. The inception period of an Agile project is typically quite bumpy and fluid within organisation used to more traditional techniques.
You should also note that the originator of the Story Point has rubbished their adoption across the Agile industry. Now, you can take that to confirm your own bias or you can take it in the spirit it was intended which is some stuff works, some stuff definitely does not work and some stuff works in some environments some of the time. Too many coaches just have a playbook of basic techniques and apply them by rote.
What should I tell my Agile Coach?
Ask him about the drawbacks and the limitations. Any good Coach should be able to inform you of why a pattern exists, who invented it, where it was pioneered and what problem it was attempting to solve. More importantly, they should simply be focussed on the real problem.
What is the quicket, most scalable, most repeatable, most sustainable way of getting business value into the hands of your customers. Story points is one part of a strategy of techniques to do that.
-
Thanks. One question though, regarding decoupling of estimates. For us in our environment, the individual edtimates matter a lot - if a slow developer is assigned a task, he will not deliver and we will not meet the deadline with that feature. How does the tesm-average estimate help? At the same time, we need work planned for everybody (8h per day) for billing- again that requires knowing who will do what and how long will it take, ballpark figures. We deliver for corporations, banks and never there was a customer who would go agile :/– John VCommented Jan 26, 2019 at 12:37
-
@JohnV - all good questions and all part of a holistic approach to Agility. A lot of the patterns and techniques that we discuss on PMSE stack on top of each other or interlink like a Venn Diagram. For instance, the rote Agile answer is that "billing per hour" is not valuable since only working software is valuable etc. Being highly focussed on individual engineers and not the team effort is also not what Agile likes to focus on. Some of these activities are anti-patterns. They might have the right intention but they are masking root causes or distracting from real issues... Commented Jan 26, 2019 at 16:04
-
...but that is not to say Agile practitioners want to disregard the real world. You clearly have a successful business and are delivering value. As you try to implement one software or team pattern you begin to adopt others. For instance, someone might ask "What is the benefit of automated testing?" and that leads to discussions on automated integration and onto automated deployment and onto the role of Ops versus Development...it is very difficult to simply take one Agile pattern in isolation without adopting the entirety of the values. My professional opinion is (like most coaches here).. Commented Jan 26, 2019 at 16:07
-
..ask yourself. Do I have a problem? If not, just improve organically. If you do, then run a few experiments. Pick one small team on a non-strategic IT project and ask them to work iteratively under the Agile values. See how it goes. Commented Jan 26, 2019 at 16:08
-
Thanks. As of now, we are jist fine, no problems. But of course I want to understand agile as it is quite common. As I say, all the articles say “with SPs, members of different speed can agree on an effort, despite their time estimates would be very different”. But they never mention what is the next step. I understand if team velocity matters, then you do not care much. But again, if you assign low perf.devs to more tasks, you might not deliver. I have read in Mike Cohn’s book that you still need to assign a person to the job..meaning not many teams are truly ceoss-functional, if any.– John VCommented Jan 27, 2019 at 9:11
You should not do "agile" just because it's "agile". If in your current approach of "fixed price, fixed time and fixed scope" every party involved is happy, then don't change anything.
I don't know where you get your time estimates from. Developers are notoriously bad at estimating time and story points are a way to make estimations better. But again, if you have time estimates and they are dead accurate then that's great. Don't change a thing.
-
They are not dead accurate, of course, all projects are planned with some padding and overhead taken into account. Because in the end, you cannot make a contract based on SP, that is not possible. I understand for product development that would work just fine, but in service delivery I have never seen a customer not wanting estimate in hours (and thus price).– John VCommented Jan 24, 2019 at 16:33
-
Of course it is possible. A CISO department offering security development work offer contracts based in story points. They took the sum of their previous year's work (3000 user stories) and their total points delivered in a year (7800 points). They divided their department budget ($1.2million) and arrived at a rough figure of $153 per complex point of effort. Easily done and their department works extremely well in a complex enterprise organisation. Now, when their developers estimate work they can charge the cost back to the business...and (cont)... Commented Jan 25, 2019 at 18:56
-
...every year they are together their algorithm gets more and more optimised. They can adjust for technology component and make good approximate calculations based on team size. Now..you might ask how about time? Simple. They have their elapsed time and cycle time for stories captured. They can make averages based on their story points, column, team member or even complexity. Or a MongoDB story takes an average of 4 days but with some outliers. All of this reporting can be automated with a good ticket tracker. You give me a well structured backlog and some empirical data and I can... Commented Jan 25, 2019 at 18:59
-
...give you a project finish date to within a fortnight and automatically adjusted for every single team event from a holiday to a loss. In an enterprise cloud project my Scrum team hit every estimate that we predicted whilst the waterfall "gateway" team refusing to adopt Agile values and practices worked late nights for 21 weeks in a row to hit "the plan." Commented Jan 25, 2019 at 19:01
Story points have a couple of advantages over time estimates.
Firstly, people often find relative sizing of tasks easier than absolute estimating (e.g. this story is twice as big as this other story, rather than this story will take 3 days).
Secondly, we use story points in conjunction with velocity, which is a measure of the rate of actual achieved completed work. This measure automatically adjusts to things that impact on the performance of the team (e.g. somebody goes off sick, a new starter has to be trained, etc.).
As a result of these advantages, story points are often a good way of predicting what your team's true capacity is. If you know your capacity then it becomes easier to understand if you are on track to make a fixed time / fixed scope deadline.
Even if you have a fixed contract this extra information can still be valuable.
By using story points you would be in a position to:
- Get early warning of possible schedule/cost over-runs
- Ask for more resource when it is needed to hit a deadline
- Understand and document any shortcuts (like cutting quality) you need to take in order to make the delivery date
Also, the use of story points does not preclude the use of time estimates. Quite a few teams I work with use both, because they see story points as a quick and simple way to estimate capacity and time estimates as necessary for other reasons (such as billing).
A common approach is to use story points at the user story level and to use time estimates at the technical sub-task level.
There is an argument that using both story points and time-based estimates is duplication. A team needs to think carefully about combining the two approaches and should evaluate if the benefits they see offset the extra effort.
answered Jan 25, 2019 at 12:41
-
But then I guess you do not have a fixed contract and a customer that expects a given set of features by a given date. I understand the idea of SPs but most people forget it works mostly in product development, not service delivery.– John VCommented Jan 25, 2019 at 16:17
-
And yes, we have adopted now this approach, to have SPs at story level with time estimates at sub-task level, although we have yet to see any benefits from that. Frankly, if you relative-estimate your story and then put time estimates for subtasks, what's the purpose? Sum of time of subtasks will be the time estimate for that story...– John VCommented Jan 25, 2019 at 16:20
-
Let me add more detail to my answer and see if that helps. Commented Jan 25, 2019 at 17:39
-
1@John - in response to your point about " In the end, it will be either done by the slower one or by the faster one, and hence the time can differ signifficantly." As a team delivering a Product, we are not interested in an individual. What we want is the average of what the team can deliver. And that is why we measure complexity. Because the work will be broadly shared around the team. So, by understanding what a team can accomplish in a timebox we can take a very accurate guess as to what a team can accomplish in 20 timeboxes. Or 52 timeboxes... Commented Jan 25, 2019 at 18:53
-
1@Venture2099 A year later, I can tell that using time estimations for subtasks and story points for stories is actually pretty good and in fixed price contracts possibly the only way - you just have to know how many hours are going to be spent/left. But that does not make SPs useless, it is good for progress visualisation, which cannot be done with hours only. We have burndown charts of features (based on SPs) but of course effort is monitored because SPs alone do not tell you whether you are on track. Another reason for time estimation of subtasks is capacity plans (no overloaded or idle ppl)– John VCommented Jan 13, 2020 at 15:33
The idea of story points is that people are terrible at writing high level estimates. A story point is relative to existing story points. So you would need a standardized, agreed on scale. A user story of this complexity is 3 story points. A larger more complex is 8 story points. Everyone agrees on the complexity of each point level.
Interestingly though, tasks within user stories are still estimated in hours. Actual time recorded is in hours.
Velocity can also be tracked in counts of completed user stories, which makes the need for story points less.
Think of three levels of details of estimates: project level, sprint level, and task level. I think your observation that you already have fixed price (estimates), fixed time, and fixed scope is good at the project level. X many people for Y time means Z cost. A technique like story points allows you to flex the scope to fit in each 2 week sprint. The sprint is always a fixed time box, but estimating features that are not fully defined yet is not accurate. There are many variables and users do not yet know what they want until they see it. Breaking a user story down into individual tasks means that the team has thought it through and defined the tasks at a well-defined, achievable level. These tasks are estimated in hours.
-
That is the thing, you still - in environment like ours - need hours at task levels. Sure, if you developer a product (which most agile blogs and articles implicitly assume) you can go without hours and truly use just velocity. But product development is a different world than service delivery.– John VCommented Jan 25, 2019 at 16:19