Estimation isn’t for everyone(open.nytimes.com)
open.nytimes.com
Estimation isn’t for everyone
https://open.nytimes.com/estimation-isnt-for-everyone-a72484f88b27?gi=b14783206ae3
87 comments
I'm undecided on scrum and story points. The most productive team I was ever on used them, but they primarily served two purposes:
* Are we breaking our work down small enough? Big stories often had too much ambiguity and increased delivery risk.
* Are we over extending ourselves? Committing to deliver too much leads to so many problems.
All estimation was done entirely async. We only debated/discussed if people had radically different views on size.
We did run daily standups, but they served as part social function (a necessary forcing function on a remote team). We did not force updates or discussion. People brought what they thought was necessary to the group and left it out otherwise.
* Are we breaking our work down small enough? Big stories often had too much ambiguity and increased delivery risk.
* Are we over extending ourselves? Committing to deliver too much leads to so many problems.
All estimation was done entirely async. We only debated/discussed if people had radically different views on size.
We did run daily standups, but they served as part social function (a necessary forcing function on a remote team). We did not force updates or discussion. People brought what they thought was necessary to the group and left it out otherwise.
You've pretty much describe where our process has been iterated to.
The story points are less about "how many hours will this take" and more "is this broken down to a manageable level".
Our team is small and we're largely working on legacy systems that nobody at the company has any clear picture on so we do still do things collaboratively in a meeting in order to quickly get to the best information we can and iterate on bits and pieces of the puzzle that may not be common knowledge.
But from there the points are mainly "Small, Medium, Big" (1-2, 3, 5). If anyone throws something out at 8 points the question is immediately whether or not we have sufficient clarity on the work. Why is this 8 points? Is it because we need to rotely reimplement the same functionality across two dozen nearly identical form fields, or is it because we've glossed over some major area of the scope and are hedging based on our _assumptions_ about how it works?
In the latter case, we'll instead see about adjusting the work breakdown and/or throwing in a ticket to actually investigate and document things better before we circle back to the original task.
If we see 13 points we know from experience to run for the hills. That's almost always someone saying "we don't have enough information, but it's going to be big".
Those points feed into two things:
1. A rough estimation of long term timelines. We know average velocity, and we can look big picture at the number of points involved in some sort of higher level initiative and get a feel for "is this a 3 month project or 12 month project?". 2. Trying not to overcommit on each sprint. We know the average we can deliver, and can use them to raise a flag when someone seems to be getting overly optimistic about their output.
Similarly, our daily standup is not focused on being a status meeting. It's to encourage communication. To help kick things off and jog people's memory, we take about 60 seconds to quickly list out tickets that are sitting in a "review" or "deploy" status (if it's nearly done let's get it over the line), "blocked" status (if you're waiting on someone, have you communicated it to them?) as well as any that, based on the points, seem to be taking longer than expected (do you need to ask someone for help or communicate changes in scope?). Then it's just hands up for anyone that needs to say anything, call for any input from the business side, some chat and banter, etc, and we're out. Usually takes about 5 minutes.
The story points are less about "how many hours will this take" and more "is this broken down to a manageable level".
Our team is small and we're largely working on legacy systems that nobody at the company has any clear picture on so we do still do things collaboratively in a meeting in order to quickly get to the best information we can and iterate on bits and pieces of the puzzle that may not be common knowledge.
But from there the points are mainly "Small, Medium, Big" (1-2, 3, 5). If anyone throws something out at 8 points the question is immediately whether or not we have sufficient clarity on the work. Why is this 8 points? Is it because we need to rotely reimplement the same functionality across two dozen nearly identical form fields, or is it because we've glossed over some major area of the scope and are hedging based on our _assumptions_ about how it works?
In the latter case, we'll instead see about adjusting the work breakdown and/or throwing in a ticket to actually investigate and document things better before we circle back to the original task.
If we see 13 points we know from experience to run for the hills. That's almost always someone saying "we don't have enough information, but it's going to be big".
Those points feed into two things:
1. A rough estimation of long term timelines. We know average velocity, and we can look big picture at the number of points involved in some sort of higher level initiative and get a feel for "is this a 3 month project or 12 month project?". 2. Trying not to overcommit on each sprint. We know the average we can deliver, and can use them to raise a flag when someone seems to be getting overly optimistic about their output.
Similarly, our daily standup is not focused on being a status meeting. It's to encourage communication. To help kick things off and jog people's memory, we take about 60 seconds to quickly list out tickets that are sitting in a "review" or "deploy" status (if it's nearly done let's get it over the line), "blocked" status (if you're waiting on someone, have you communicated it to them?) as well as any that, based on the points, seem to be taking longer than expected (do you need to ask someone for help or communicate changes in scope?). Then it's just hands up for anyone that needs to say anything, call for any input from the business side, some chat and banter, etc, and we're out. Usually takes about 5 minutes.
> Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed.
That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label?
Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.
That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label?
Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.
> That's because indirectly you're suggesting to get rid of people as well.
That could have certainly been the case in some cases (the overpaid British corporate Scrum master consultant).
For the product owners, it could have been the "nobody gets fired for buying IBM": nobody gets reprimanded in a traditional, slow moving, German company for sticking to the same ol Scrum ceremonies.
For some developers, they might have valued the meetings for the pointlessness of it: just say your internet is poor, turn off the camera, then do the dishes, take out the trash, jump in with a hot take to start another 20 discussion in the call, go on to working out, and preparing dinner.
After I failed to make any change in the organization after a year of trying, I switched my modus operandi to the above described developer, and started looking for another job.
That could have certainly been the case in some cases (the overpaid British corporate Scrum master consultant).
For the product owners, it could have been the "nobody gets fired for buying IBM": nobody gets reprimanded in a traditional, slow moving, German company for sticking to the same ol Scrum ceremonies.
For some developers, they might have valued the meetings for the pointlessness of it: just say your internet is poor, turn off the camera, then do the dishes, take out the trash, jump in with a hot take to start another 20 discussion in the call, go on to working out, and preparing dinner.
After I failed to make any change in the organization after a year of trying, I switched my modus operandi to the above described developer, and started looking for another job.
This stuff is to keep people employed, 100%. 10+ years ago, engineering teams didn't have as much overhead.
> I'll not work for a company with Scrum and story point estimations.
I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout.
I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout.
> I made the career decision of no longer accepting positions at agile shops at all
I'm legitimately curious what the alternative is. You refuse to work anywhere that starts programming before they have a complete specification of what they're building? You only work at places where you have a fixed spot in the waterfall model? Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
I'm legitimately curious what the alternative is. You refuse to work anywhere that starts programming before they have a complete specification of what they're building? You only work at places where you have a fixed spot in the waterfall model? Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
In my decades of being in the industry, I've never actually seen anyone use the "waterfall" method as described by the agile crowd anyway. If I did, I'd avoid working there as well.
> You only work at places where you have a fixed spot in the waterfall model?
Nope. I've never worked at a place that used the "waterfall" model in my entire career. I'm not saying they don't exist, just that I've never seen one.
> Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
What? That sounds like a nightmare.
Your impression of what non-agile development looks like bears no resemblance to what I've seen and experienced.
The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall.
> You only work at places where you have a fixed spot in the waterfall model?
Nope. I've never worked at a place that used the "waterfall" model in my entire career. I'm not saying they don't exist, just that I've never seen one.
> Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
What? That sounds like a nightmare.
Your impression of what non-agile development looks like bears no resemblance to what I've seen and experienced.
The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall.
> The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall.
Maybe I've just got the entirely wrong conceptualization in my head here, but to me you're comparing apples and oranges.
Agile is the idea that "we should be doing small pieces of work, collecting new information, communicating with business and customer stakeholders and integrating it, then tackling our next piece of work".
Waterfall is the idea that "we should know everything we're doing up front before we start".
These are the two extremes of the same spectrum.
Scrum, kanban, reams of paper, and everything else are implementations to turn these philosophies (or places in between them on the spectrum) into actionable processes.
To my understanding (and from some brief sanity checks around the internet), kanban _is_ "Agile". If it isn't to you, then what is your understanding of "Agile"?
Editing to add: Most of this understanding comes from having worked a lot of places that did waterfall-scrum or waterfall-kanban. You can have as many sprint rituals as you want, but if nobody is assigned any tickets or starts working on projects until you've documented every minute detail from beginning through to release of a full product... you're doing waterfall, not agile.
Maybe I've just got the entirely wrong conceptualization in my head here, but to me you're comparing apples and oranges.
Agile is the idea that "we should be doing small pieces of work, collecting new information, communicating with business and customer stakeholders and integrating it, then tackling our next piece of work".
Waterfall is the idea that "we should know everything we're doing up front before we start".
These are the two extremes of the same spectrum.
Scrum, kanban, reams of paper, and everything else are implementations to turn these philosophies (or places in between them on the spectrum) into actionable processes.
To my understanding (and from some brief sanity checks around the internet), kanban _is_ "Agile". If it isn't to you, then what is your understanding of "Agile"?
Editing to add: Most of this understanding comes from having worked a lot of places that did waterfall-scrum or waterfall-kanban. You can have as many sprint rituals as you want, but if nobody is assigned any tickets or starts working on projects until you've documented every minute detail from beginning through to release of a full product... you're doing waterfall, not agile.
What makes you think anyone works like that ? It’s crazy that agile people paint the rest of the world as if it was like that..
I worked in (too) large scrum team and frustrated, at some point, I also pulled data from Jira. It turned out that our actual pace of work was a fraction of the velocity we used to determine which task to take up into sprint.
There can be a lot of scrum theatre played entirely for the management and divorced from reality. Influence on the work done is completely secondary.
But I find it completely natural that in corporations most important function of a lot of things is providing everyone sufficient excuse to get paid.
There can be a lot of scrum theatre played entirely for the management and divorced from reality. Influence on the work done is completely secondary.
But I find it completely natural that in corporations most important function of a lot of things is providing everyone sufficient excuse to get paid.
Oof. I had to do the double daily standup thing once. In addition to the retros, calls with subject matter experts, company meetings, etc. By the time we could actually get started on sprint work, and do a couple hours work here and there between meetings, it was almost sprint deadline already.
I didn't even bother with pulling data from Jira and trying to make a point that way. It wasn't necessary.
I just quite honestly gave my update in my second standup "No progress since the last meeting because I've been in meetings since then."
Some people were a little rankled by that honesty. But eventually they got the point and scrapped that second hour of standup and some of the other meetings. That helped significantly.
I didn't even bother with pulling data from Jira and trying to make a point that way. It wasn't necessary.
I just quite honestly gave my update in my second standup "No progress since the last meeting because I've been in meetings since then."
Some people were a little rankled by that honesty. But eventually they got the point and scrapped that second hour of standup and some of the other meetings. That helped significantly.
Exactly the same reasons - “management wants numbers” with most of the clients I’ve worked with over the past 3 years. It’s such an incredible was of time that most of us have given up and pick a random number between 2 and 5.
I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely alone. I had no choice but to follow good practice to maintain them alone.
I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go.
I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go.
Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal.
Very well put.
I tried being non-judgemental about agile -- first by trying to be objectively detached ("I'm not sure I can believe in this, but okay, let's see if it works.") And then by applying the serenity prayer ("I can't pretend to believe this any value any more, but hey, it's their company, whatever makes them happy.")
The tipping point came for when I did the math, and realized there was a profoundly strong inverse correlation between how woo-woo management was about agile, and actual engineering competence -- or even basic communication skills and social competence (at you know, actually collaborating with others and treating them with respect; managing one's emotions instead of repeatedly creating drama over utter trivialities, etc).
The low-competence, low-trust environments -- where management lied and back-stabbed every chance it could get -- loved agile. The high-competence, high-trust environments couldn't give a flying fuck about agile.
So now I'm with this commenter, and their sage advice:
https://news.ycombinator.com/item?id=36358127
And no, I'm not going to capitalize the word "agile", either. Or waste any more time with anyone who does.
Very well put.
I tried being non-judgemental about agile -- first by trying to be objectively detached ("I'm not sure I can believe in this, but okay, let's see if it works.") And then by applying the serenity prayer ("I can't pretend to believe this any value any more, but hey, it's their company, whatever makes them happy.")
The tipping point came for when I did the math, and realized there was a profoundly strong inverse correlation between how woo-woo management was about agile, and actual engineering competence -- or even basic communication skills and social competence (at you know, actually collaborating with others and treating them with respect; managing one's emotions instead of repeatedly creating drama over utter trivialities, etc).
The low-competence, low-trust environments -- where management lied and back-stabbed every chance it could get -- loved agile. The high-competence, high-trust environments couldn't give a flying fuck about agile.
So now I'm with this commenter, and their sage advice:
https://news.ycombinator.com/item?id=36358127
And no, I'm not going to capitalize the word "agile", either. Or waste any more time with anyone who does.
I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira.
To be fair I've seen some people interpret the manifesto to mean "never document anything or take time to introspect", which leads to its own set of problems.
As with everything, a purposeful balance is best imo.
As with everything, a purposeful balance is best imo.
It's a result of a more fundamental problem that was present from very early on: at most companies, "doing agile" is not for the benefit of the development process or developers, but for upper management.
The people who were capable continued to program, while the incapable ones found an easier career path through Agile.
-- Manifesto for Half-Arsed Agile Software Development --
We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value:
# 1. Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact
# 2. Working software over comprehensive documentation
as long as that software is comprehensively documented
# 3. Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
# 4. Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.
-- https://www.halfarsedagilemanifesto.org/
We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value:
# 1. Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact
# 2. Working software over comprehensive documentation
as long as that software is comprehensively documented
# 3. Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
# 4. Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.
-- https://www.halfarsedagilemanifesto.org/
Well, those consultants sound very afFORDable.
"You can have any color car you like, as long as it's black."
- Henry Ford
"You can have any color car you like, as long as it's black."
- Henry Ford
The same way people went from "everyone should be equal" to Stalin.
In comparison, Jira's not so bad...
In comparison, Jira's not so bad...
Modern day salt mines would definitely have a kanban board though
|Current |Near Term|Future |Wish List|
|Mine Salt|Mine Salt|Mine Salt|Mine Salt|
|Mine Salt|Mine Salt|Mine Salt|Breaks? |
|Mine Salt|Mine Salt|Mine Salt|Mine Salt|
|Mine Salt| |Mine Salt|Lick Salt|
|Mine Salt| | | |Modern software development is so detached from what makes software useful - getting it used. All the practices people have been preaching doesn't include the context that making sure the piece of code they written is getting used. It's like running a restaurant and all that people care is keeping the lightbulbs up.
This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering value to the end customer and the business. Meaning, they’re really interested in building software and features that people actually use.
As someone building something to tackle this problem, I'm under the impression that your situation is rare. Google famously kills product loved by customer. Reddit is committing suicide. facebook (almost) never built anything useful. I would love to learn from you how your team build software that matters if you don't mind.
I think those big companies are poor examples, as big companies have always more problems with aligning people around customer needs/business priorities. There's a lot more of corporate politics that takes time and a lot more money to waste (when the core business itself is highly profitable). If you look at the smaller companies (e.g. Linear.app) it is immensely hard to argument that they would not be building "useful software."
In our case, we stay close to the customer. Some ways we achieve this:
- We have a shared Slack channels with at least 20 customers. All engineers are on these channels and see the communications that is going on.
- All engineers work with customer support 1 week every X weeks. All engineers are on the support channel too and see the topics of the tickets / customer requests. - We gather customer feedback for feature requests and all new features are based on business priorities informed by this feedback.
- PMs and Designers regularly talk with customers when doing product research. When we have an idea of what we might want to build, 1-2 engineers join them in shaping an Epic (size: 1-2 months) or a Story (size: ~2 weeks). One of these engineers will lead the Epic/Story, which means that they amass a lot of context of the both problems of the customers and the technical details of the solution. Usually they are able to do much of the scoping/product decisions quite quickly after the Epic/Story has started.
- Engineers watch a sales / customer success call every two weeks and then join to discuss the contents of the call together.
In our case, we stay close to the customer. Some ways we achieve this:
- We have a shared Slack channels with at least 20 customers. All engineers are on these channels and see the communications that is going on.
- All engineers work with customer support 1 week every X weeks. All engineers are on the support channel too and see the topics of the tickets / customer requests. - We gather customer feedback for feature requests and all new features are based on business priorities informed by this feedback.
- PMs and Designers regularly talk with customers when doing product research. When we have an idea of what we might want to build, 1-2 engineers join them in shaping an Epic (size: 1-2 months) or a Story (size: ~2 weeks). One of these engineers will lead the Epic/Story, which means that they amass a lot of context of the both problems of the customers and the technical details of the solution. Usually they are able to do much of the scoping/product decisions quite quickly after the Epic/Story has started.
- Engineers watch a sales / customer success call every two weeks and then join to discuss the contents of the call together.
Agile is a process (or a school of processes) for planning and building software to meet business goals. We can debate whether or not it's good at that, but ultimately if the business goals are misguided, or user-hostile, or both, agile isn't really to blame here.
However if agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame.
We are all "self-taught", we learn by research, experience and by working with others. Stuff we learn at undergraduate (sometimes graduate) school is pretty much useless from a pure software engineering perspective. What we learn in school is how to do research which makes the learning part easier.
As far as estimations go, unfortunately companies are no charities. There's usually a limited yearly budget that needs to be allocated to each team to build things that make the company a profit, so sometimes estimations are a necessary evil for managers to negotiate that budget and align their resources. It's not a perfect science and it is not expected to be.
Also in some business domains estimations can be easy and highly accurate, so they are not necessarily pseudo science for everyone.
In any case, the ability to provide estimates with lack of information is a skill that all experienced software engineering must have.
As far as estimations go, unfortunately companies are no charities. There's usually a limited yearly budget that needs to be allocated to each team to build things that make the company a profit, so sometimes estimations are a necessary evil for managers to negotiate that budget and align their resources. It's not a perfect science and it is not expected to be.
Also in some business domains estimations can be easy and highly accurate, so they are not necessarily pseudo science for everyone.
In any case, the ability to provide estimates with lack of information is a skill that all experienced software engineering must have.
uw7ssh8shs8(1)
You really do gotta keep things organised when you have a lot of Devs working on the same project. There are of course right amounts for right team size/task, but I've worked at startups growing where people started off with the individual contributor mindset and it became unmanageable as more people joined
I think it all boils down to the (people that know what are doing)/(people who don't know what are doing or don't care) ratio.
If the first group is dominant, agile is mostly about time-wasting rituals. Eventually, when the numbers of the second group swell, agile starts becoming useful.
If the first group is dominant, agile is mostly about time-wasting rituals. Eventually, when the numbers of the second group swell, agile starts becoming useful.
I don't think that anyone is arguing that there's no need for project management.
My guess is you have a layer of "professional planners" that fiddling with dates and projections is what they do. Agreed it's mostly a waste of time.
> And everybody is focusing so much on the estimates, tickets like this was the end goal
It is. The end goal is not to build something. It is to provide everyone sufficient excuse to get paid for a period of time.
It is. The end goal is not to build something. It is to provide everyone sufficient excuse to get paid for a period of time.
Worse yet, with all those estimates and commitments we look like we only make progress when doing features that the business looks for.
Other things just aren't valued.
Other things just aren't valued.
Oh you want some kind of numerical estimation measure?
<Rolls 1DFibonacci in his mind>
It's a three. Have fun!
---
Unless it's something I've actually implemented before - this is pretty much what I do these days. You can sprint plan all you like - but in my arena (front-end) there are so many things that can mess up your best laid implementation plans. So in such a scenario - I agree with the article. Just get on with it. Do a quick, rough plan and get to coding up a rough PoC that validates the approach as quickly as possible.
Folks get anxious when there is implementation uncertainty. And I've learned that voicing this uncertainty just erodes their trust. If I do discover a problem with my implementation that is going to cost some extra time - then they generally have no problem with that as long as I communicate the discovery promptly along with a confident appraisal of the effectiveness of my new approach.
Folks are fine with mistakes that happened in the past. They only fear the possibility of mistakes in the future.
<Rolls 1DFibonacci in his mind>
It's a three. Have fun!
---
Unless it's something I've actually implemented before - this is pretty much what I do these days. You can sprint plan all you like - but in my arena (front-end) there are so many things that can mess up your best laid implementation plans. So in such a scenario - I agree with the article. Just get on with it. Do a quick, rough plan and get to coding up a rough PoC that validates the approach as quickly as possible.
Folks get anxious when there is implementation uncertainty. And I've learned that voicing this uncertainty just erodes their trust. If I do discover a problem with my implementation that is going to cost some extra time - then they generally have no problem with that as long as I communicate the discovery promptly along with a confident appraisal of the effectiveness of my new approach.
Folks are fine with mistakes that happened in the past. They only fear the possibility of mistakes in the future.
A three is fine. (Or a two. Whatever you want it to be.) In fact, everything is a three. (Or a two.) If it's a five, or an eight, it just needs to be broken up further, until it's a three. (Or a two. You see, I don't care.)
If you don't know yet how to break it up, you need a spike. A spike is... you guessed it, a three. (Or...)
My point (pun intended), the points are for discussion, not for measurement.
If you don't know yet how to break it up, you need a spike. A spike is... you guessed it, a three. (Or...)
My point (pun intended), the points are for discussion, not for measurement.
This is correct. There's lots of people in here complaining with all the authority of experience when in fact, they're complaining that the ruler they're using to measure a mile is too small. Throw rulers in the bin! Down with measuring all together!
Engineering needs risk management, accurate estimation and prediction, cost control and all the other things SWEs tend to thumb their nose at.
If you think something is crap, chances are you're using it wrong or don't understand. Sadly software is filled with "smartest person in the room" types who think if they don't understand something, then it is clearly not them at fault!
Pop your ego aside and ask. People like Sverhagen actually know what the tool should be used for.
Sadly software isn't building a house, assembling a car or any other engineering task with very uniform and predictable discrete components ... so we need measures that deal with the ambiguity, complexity and attempt to measure inaccuracy accurately.
Estimation with something like a fib sequence is designed to abstractly encapsulate the real-world impact of a task in terms of risk, effort, unpredictability, variability and so on.
Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns.
Sadly unsuprising that many offer no alternative, just complaints and bluster.
Engineering needs risk management, accurate estimation and prediction, cost control and all the other things SWEs tend to thumb their nose at.
If you think something is crap, chances are you're using it wrong or don't understand. Sadly software is filled with "smartest person in the room" types who think if they don't understand something, then it is clearly not them at fault!
Pop your ego aside and ask. People like Sverhagen actually know what the tool should be used for.
Sadly software isn't building a house, assembling a car or any other engineering task with very uniform and predictable discrete components ... so we need measures that deal with the ambiguity, complexity and attempt to measure inaccuracy accurately.
Estimation with something like a fib sequence is designed to abstractly encapsulate the real-world impact of a task in terms of risk, effort, unpredictability, variability and so on.
Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns.
Sadly unsuprising that many offer no alternative, just complaints and bluster.
> Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns.
I think most software engineers know this. In my experience, the problem is that management doesn't.
I think most software engineers know this. In my experience, the problem is that management doesn't.
This is basically what we've come to. We don't force break down until 13. There are occasions where it's either (1) far easier to keep something as one, large piece (2) it's not really feasible to break down further.
Ideally, most stories should be 3 or 5 pointers.
Ideally, most stories should be 3 or 5 pointers.
Even for a 5 I would encourage a discussion to see if it is worthwhile to be split up. Smaller stories lead to smaller code reviews, easier for the code reviewer, quicker updates in standup, no one falling behind. You can still decide to keep the occasional 5, but it's worth the discussion.
That depends significantly on your team's measure of points. My team would never waste time trying to split a 5. But a 34, we would almost always try to split.
21s, we try to limit how many of them there are, but we're wary of splitting too much because splitting them up into, say, three separate 8s and then having to add a 13 to puzzle piece them all back together again isn't necessarily an improvement.
But I think our points scale is quite different from what many other teams use. In any case, you have to be wary of splitting things too much (or not enough). If your 'bricks' are 8s, 13s, and 21s, then splitting a 5 is just making more work. But if your 'bricks' are 1s, 2s, and 3s, then splitting a 5 may well be a good idea.
21s, we try to limit how many of them there are, but we're wary of splitting too much because splitting them up into, say, three separate 8s and then having to add a 13 to puzzle piece them all back together again isn't necessarily an improvement.
But I think our points scale is quite different from what many other teams use. In any case, you have to be wary of splitting things too much (or not enough). If your 'bricks' are 8s, 13s, and 21s, then splitting a 5 is just making more work. But if your 'bricks' are 1s, 2s, and 3s, then splitting a 5 may well be a good idea.
It sounds like you're team has anchored around 13 as what we'd call our 5.
Neither is right or wrong, just different.
Neither is right or wrong, just different.
Well, it's about story points rather than estimation per-se. The alleged inventor of story points says their invention was probably a mistake: https://ronjeffries.com/articles/019-01ff/story-points/Index...
But most people ultimately want estimates to determine whether or not a project is going to be late or over budget (often the same thing). What's worked for me is to ensure the stories are of the same sort of size (ie they mostly sort of look like they could be done in a few hours/days/week/months) - count them up and divide by remaining time. You'll then get an idea of whether you'll need to deliver 2 things a week or 50 - and you'll have a gut feel on whether that's achievable.
But most people ultimately want estimates to determine whether or not a project is going to be late or over budget (often the same thing). What's worked for me is to ensure the stories are of the same sort of size (ie they mostly sort of look like they could be done in a few hours/days/week/months) - count them up and divide by remaining time. You'll then get an idea of whether you'll need to deliver 2 things a week or 50 - and you'll have a gut feel on whether that's achievable.
This works well, if the size of the stories is small enough.
When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
The slicing is the difficult part. Especially when there are so many dependencies, so many things are intertwingled, you need both back-end and front-end and maybe migrations and configuration to support this new thing. A legacy system has to work with an API, and there are permissions and data structures and so on that need to be right just for the bare minimum.
There's only so far you can go with feature flags and "work in progress" changelogs. Plus having to beware shattering things into tiny pieces and then having to puzzle them all back together at end of sprint with code conflicts and tests that now fail when you combine things and maybe missing or incompatible bits that would've worked better if at least these pieces had been built wholistically.
You can only get so small before you're actually making more work and more potential for inconsistencies and delays.
All the tech stuff we do is relatively much easier in comparison to figuring out how to slice it well. That's the perennial challenge. Design, optimization, security - all are challenging topics, but none nearly as challenging as slicing things optimally.
There's only so far you can go with feature flags and "work in progress" changelogs. Plus having to beware shattering things into tiny pieces and then having to puzzle them all back together at end of sprint with code conflicts and tests that now fail when you combine things and maybe missing or incompatible bits that would've worked better if at least these pieces had been built wholistically.
You can only get so small before you're actually making more work and more potential for inconsistencies and delays.
All the tech stuff we do is relatively much easier in comparison to figuring out how to slice it well. That's the perennial challenge. Design, optimization, security - all are challenging topics, but none nearly as challenging as slicing things optimally.
Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-term throughput and more developer flow time, but less collaboration, knowledge-sharing, and predictability.
You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2.
For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).
You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2.
For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).
Agreed. But and then... making small stories only works well for a limited horizon. So, now your estimating only works for planning ahead a limited time. You use that to build a general confidence in having a constant stream of feature output. And the same people can then make some assumptions about future projects, based on similar projects in the past. Which works great for feature factories, less so for committing to a tight, hard deadline for a big project that exceeds the limited horizon.
This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.
You probably didn't mean that double-negative there. But still, scope may be set in stone from someone's perspective, but unless the circumstances are very exceptional, things tend to get uncovered as you move through the project that will upset the detailed plan. I just think that big projects have to assume a certain amount of uncertainty. Stakeholders will often accept some of that uncertainty if you have a proven track record of steady (feature) output. One of YOUR stakeholders may take it upon them to turn their confidence into an external commitment, but they should then also have the sway to deal with their error in judgement, and so on.
Need to be sized appropriately to the project and planning exercise. Small stories for short projects, larger ones for large projects. Probably a bit of Goldilocks at play here.
Back in the late 80s we called that Release Management, and was fixed capacity bundling small maintenance and improvement tickets, executed in 3-4 weeks - waterfall - methodology. Funny how our discipline is stuck in a circle of perpetual re-discovering the past. Maybe we don’t deserve the title of Engineers and should be Software Artisans.
Large projects were still the multi month waterfall that got so poor fame (a bit unfairly I might add)
Quality of the team is the key. Methodology is secondary.
Large projects were still the multi month waterfall that got so poor fame (a bit unfairly I might add)
Quality of the team is the key. Methodology is secondary.
Just before I left my last gig, I was toying with an idea similar to this.
The idea was that our daily “standup” would be entirely asynchronous, prompted via a Slack bot.
The bot would grab our in-progress tickets and ask us about each one in turn. For each ticket we give a “gut check”, which is how far towards completion we feel we are (expressed as a simple percentage).
A core idea is that it’s not expected for the dev to be accurate in this assessment, just to be an honest guess.
Over time the bot would collect and run some analysis on this data, and would then know the average velocity of the team on a per-dev or per-ticket basis.
I still like the idea, even though I’ve never implemented it in practice. One glaringly obvious fault is that it can’t really account for outliers. But relying on percentiles rather than averages might alleviate some of that.
The idea was that our daily “standup” would be entirely asynchronous, prompted via a Slack bot.
The bot would grab our in-progress tickets and ask us about each one in turn. For each ticket we give a “gut check”, which is how far towards completion we feel we are (expressed as a simple percentage).
A core idea is that it’s not expected for the dev to be accurate in this assessment, just to be an honest guess.
Over time the bot would collect and run some analysis on this data, and would then know the average velocity of the team on a per-dev or per-ticket basis.
I still like the idea, even though I’ve never implemented it in practice. One glaringly obvious fault is that it can’t really account for outliers. But relying on percentiles rather than averages might alleviate some of that.
Every story (or task) you're working on should be so small that if you're working on it for more than two or three subsequent daily stand-ups, alarm bells should go off. In your supportive team that means someone notices this during standup and offers to help get you unblocked.
That assumes that you're blocked, not making progress every day. If a task typically involves a combination of data structuring, some business logic, and the UI for it, as well as any necessary API, integrations, migrations, and of course automated tests for all that, then it might take more than a couple days. Doesn't mean you're blocked. You say when you're blocked, the clock doesn't.
I don't know, if tasks have that many internal dependencies, maybe they should be separate tasks, and then don't pick up a task when it has unresolved dependencies. But sure, reality happens too, I don't want to say that what I'm describing is perfect.
That requires that your tickets be atomic enough, meaning project management and planning is still required . Or you’ll end up on a single mega-ticket the entire time.
That’s not a bad idea. Especially given that estimation datasets are extremely small, this could quickly give some better data.
Subtle point, possibly, but:
> It’s important to note, though, that the throughput metric applies to teams. An individual does not complete a certain number of points per week. This is an important distinction, because you don’t want your developers to feel judged by the system, or to try to game it by engineering the tickets they take on.
This is true, but it's not the main reason to treat the team as the unit of delivery. It's because total team delivery isn't the sum of individual delivery: to treat it like that would be to miss the incidental sideways contributions all the team members have on each others' tickets. If you're doing it right, your most capable people might have very low individual throughputs because they're lifting everyone else up.
> It’s important to note, though, that the throughput metric applies to teams. An individual does not complete a certain number of points per week. This is an important distinction, because you don’t want your developers to feel judged by the system, or to try to game it by engineering the tickets they take on.
This is true, but it's not the main reason to treat the team as the unit of delivery. It's because total team delivery isn't the sum of individual delivery: to treat it like that would be to miss the incidental sideways contributions all the team members have on each others' tickets. If you're doing it right, your most capable people might have very low individual throughputs because they're lifting everyone else up.
Estimation, especially story points are just a tool to help you communicate and talk about the size of work.
Most of the time it’s likely to average just under a 5, so you round up, as most work will fit within a week, which is the underlying “effort” you’re getting from velocity.
For a team of seasoned developers you might as well make everything a one and go kanban.
Most of the time it’s likely to average just under a 5, so you round up, as most work will fit within a week, which is the underlying “effort” you’re getting from velocity.
For a team of seasoned developers you might as well make everything a one and go kanban.
Gonna suggest this at my company, see y'all on the stake they'll burn me on
They might; I suggested we give everything a two, because that’s what the point value was most of the time.
I added some thing along the lines of “it will take the time it will take regardless of whatever point value we assign to it.“
I added some thing along the lines of “it will take the time it will take regardless of whatever point value we assign to it.“
I resonate with several points.
I worked at a place for tickets could have a value of : 1,2,3,5
Most of the time it was a 2, with the occasional 1,3. It’s as if some devs enjoyed the time wasted on the banter if we had a fat one or a skinny two or a fat too, or skinny three. It was such a waste.
At one point, I said we should just give everything a 2 because in the end it will take the amount of time that it will take. Regardless of whatever point we assign this ticket.
I don’t miss that job. We spent more time grooming and planning and doing retros instead of collaborating.
Most of the time it was a 2, with the occasional 1,3. It’s as if some devs enjoyed the time wasted on the banter if we had a fat one or a skinny two or a fat too, or skinny three. It was such a waste.
At one point, I said we should just give everything a 2 because in the end it will take the amount of time that it will take. Regardless of whatever point we assign this ticket.
I don’t miss that job. We spent more time grooming and planning and doing retros instead of collaborating.
The article buried it a bit: cycle time. Reducing cycle time means more value faster. This is a good metric for driving discussions.
As for points, the best system I've worked with is 1, 2, or 3 points.
1: we know exactly what to do.
2: we have an idea what to do and we feel the story should not be broken up any further.
And 3: we don't know how to solve this; break it up or create a spike to study the problem to break it down or accept the unknown.
Everything practically becomes a 2, and is thus in line with the article - the number of stories is pretty reliable between sprints and for projections.
The advantage of 1, 2, or 3 over "no points" is that it drives conversions on if something should be broken down. The team quickly starts creating tickets that generally are 2s and pointing a story typically takes a team of 6-8 about 10 seconds. A 3 may be talked about for a minute before it is accepted or broken up as agreed to by the group.
As for points, the best system I've worked with is 1, 2, or 3 points.
1: we know exactly what to do.
2: we have an idea what to do and we feel the story should not be broken up any further.
And 3: we don't know how to solve this; break it up or create a spike to study the problem to break it down or accept the unknown.
Everything practically becomes a 2, and is thus in line with the article - the number of stories is pretty reliable between sprints and for projections.
The advantage of 1, 2, or 3 over "no points" is that it drives conversions on if something should be broken down. The team quickly starts creating tickets that generally are 2s and pointing a story typically takes a team of 6-8 about 10 seconds. A 3 may be talked about for a minute before it is accepted or broken up as agreed to by the group.
You’ve basically got small, big, and too big. Which is pretty close to my favored model.
FDD is rarely seen but it didn’t do points, it did the Law of Large Numbers.
When you have 400 stories you can build trends off of them.
FDD is rarely seen but it didn’t do points, it did the Law of Large Numbers.
When you have 400 stories you can build trends off of them.
I think agile estimation is a good pretext to have a discussion about work where things come to attention and things get split up if they begin looking too large. Disciplined and insightful developers can have this discussions spontaneously but those are not the people those rituals are for.
Points and velocity are orthogonal to this. They might give overseers the added benefit of having some estimate. But they bring along the risk that they'll be used for performance assessment which makes them useless for any estimations and horrible for assessment and bring inefficiencies inyo the discussion during estimation and planning.
If points were averaged or forgotten after planning for some teams it might work better.
Points and velocity are orthogonal to this. They might give overseers the added benefit of having some estimate. But they bring along the risk that they'll be used for performance assessment which makes them useless for any estimations and horrible for assessment and bring inefficiencies inyo the discussion during estimation and planning.
If points were averaged or forgotten after planning for some teams it might work better.
I am a data scientist hired this year at a 30-employee company where I am the only programmer. I meet with my boss about weekly to discuss progress and what to work on. How should solo programmers "estimate"?
It sounds like you're probably doing appropriate estimations when you meet with your boss.
[deleted]
I almost didn't the article because wth can NYT tell us about agile software? Some thrice-washed-down generalization for the masses, full of holes?
Turns out it's from their dev blog and it's an interesting read.
Turns out it's from their dev blog and it's an interesting read.
To ask a question probing at the title... who _is_ it for?
Who's doing such well known repetitive tasks that they also need estimation for?
Circular black hole imo.
Who's doing such well known repetitive tasks that they also need estimation for?
Circular black hole imo.
I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had the honour to be selected to work as an external examiner for CS students for the past 6 or 7 years. I’ve spent most of my time in non-tech enterprise organisations, and recently working with non-tech start-ups that are transitioning into enterprise organisations. In my years in the public sector I had the fortune to both make an impact on our national strategies and work along some of the best talent in the Danish Software Industry, both from major software houses and tiny ones.
I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools.
This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines.
I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for “how to work” intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work.
I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets “agile good, waterfall bad” into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your “we don’t know what features we can finish” contract. Or that everyone basically expects your estimates and deadlines to fail.
Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun.
Anyway. I tend to take the “easy” road. I fairly quickly figured out management wasn’t for me. I’ll still do architecture, but I’ll never do it in a way that dictates anything by ever again, enable? Sure, but I won’t boss devs around. Mostly though, I’ll work with development and try to help teams become efficient at building software with the least project management possible. We’ll the PM people be PMs and then let them send their user stories or whatever format they want to the developers once they are deemed so ready that a fresh hire could program them in whatever way they want. Then on the programming side, we streamline as much of the process as possible so they developers won’t have to make a lot of infrastructure or coding-standards decisions, but see completely free to just work on coding. I like that, and as long as our business has enough of a need for developers, I’d encourage people to find what they like and work in that. So when the head hunters contact you, ask them what sort of processes they have, and if they say stuff you don’t like, then hang up. That way you’ll never have to do estimation again unless you chose to. At least for as long as we’re in a buyers market. Once that ends, there is always woodworking.
I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools.
This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines.
I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for “how to work” intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work.
I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets “agile good, waterfall bad” into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your “we don’t know what features we can finish” contract. Or that everyone basically expects your estimates and deadlines to fail.
Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun.
Anyway. I tend to take the “easy” road. I fairly quickly figured out management wasn’t for me. I’ll still do architecture, but I’ll never do it in a way that dictates anything by ever again, enable? Sure, but I won’t boss devs around. Mostly though, I’ll work with development and try to help teams become efficient at building software with the least project management possible. We’ll the PM people be PMs and then let them send their user stories or whatever format they want to the developers once they are deemed so ready that a fresh hire could program them in whatever way they want. Then on the programming side, we streamline as much of the process as possible so they developers won’t have to make a lot of infrastructure or coding-standards decisions, but see completely free to just work on coding. I like that, and as long as our business has enough of a need for developers, I’d encourage people to find what they like and work in that. So when the head hunters contact you, ask them what sort of processes they have, and if they say stuff you don’t like, then hang up. That way you’ll never have to do estimation again unless you chose to. At least for as long as we’re in a buyers market. Once that ends, there is always woodworking.
I spent a few years working in a project (program?) management office as an administrative assistant.
Somewhere in there, I announced to my manager that I had figured out how to accurately estimate the time a project would take - of course historically we had all sorts of overruns.
I had reviewed records of hundreds of past IT projects and found that they averaged a nice round 2x estimates.
Therefore, obviously, a simple methodology of evaluating all known factors as usual and doubling the result would lead to dramatically better planning and resource usage.
But...you can't just do that, any more than you can simply walk into Mordor.
Somewhere in there, I announced to my manager that I had figured out how to accurately estimate the time a project would take - of course historically we had all sorts of overruns.
I had reviewed records of hundreds of past IT projects and found that they averaged a nice round 2x estimates.
Therefore, obviously, a simple methodology of evaluating all known factors as usual and doubling the result would lead to dramatically better planning and resource usage.
But...you can't just do that, any more than you can simply walk into Mordor.
Early in my career, I once worked with someone who estimated 40 hours for anything and everything, every single time.
Need to change some text here? "Well, it's a complex system and we'll have to think about translations and if the same text is used anywhere else, whether it will affect the layout, etc., etc. - 40 hours."
Need to build a whole new system from scratch? "Well, we have experience in that and it's a small enough data set and we have tools to help us - 40 hours."
If it was a trivial change, then they had most of the week free to do whatever.
If it was a huge project, then they'd go back and say "We need to reduce scope. They said they wanted X, but that actually wouldn't be good for them because of Y. We shouldn't do that, and they'll be glad we didn't."
Somehow, this one person always managed hit their estimates spot-on, every time. This was a model employee.
Depending on the company and your management, and how well you can BS, you can simply walk into Mordor whenever you feel like it.
Need to change some text here? "Well, it's a complex system and we'll have to think about translations and if the same text is used anywhere else, whether it will affect the layout, etc., etc. - 40 hours."
Need to build a whole new system from scratch? "Well, we have experience in that and it's a small enough data set and we have tools to help us - 40 hours."
If it was a trivial change, then they had most of the week free to do whatever.
If it was a huge project, then they'd go back and say "We need to reduce scope. They said they wanted X, but that actually wouldn't be good for them because of Y. We shouldn't do that, and they'll be glad we didn't."
Somehow, this one person always managed hit their estimates spot-on, every time. This was a model employee.
Depending on the company and your management, and how well you can BS, you can simply walk into Mordor whenever you feel like it.
Well...I mean it's a logical conundrum because if you take the timeframe you can justify and double it, by definition you can't justify half of the time it will take.
On the other hand, a minimum amount of time required for a project seems to be well accepted by project managers and others.
On the other hand, a minimum amount of time required for a project seems to be well accepted by project managers and others.
So . . . article claims not just estimation (which is not agile - we all always estimate!) doesn't work, but the rest doesn't work, too.
This is obvious BS. Not sure why, though . . .
Because the author complains a lot but really doesn't exactly say . . .
This is obvious BS. Not sure why, though . . .
Because the author complains a lot but really doesn't exactly say . . .
NYT is an expert body on software development now?
I cannot say about NYT, but a lot of newspapers have amazing tech teams. The tech team at FT has an excellent reputation. Unfortunately, some tabloids also have really good tech teams, but I shall not name them because they sell toxicity.
I once lead the tech team at a smaller news outlet.
Software developers join the news and media business because there is a lot of interesting high-load work, the competition in the business is fierce, so engineering tends to be frugal and good.
Journalists usually own the copyright to their writings, which by extension applies to software developers working in the same business.
Unfortunately, the pay is below the market, people come, enjoy coding, beef up their resume and github profiles with open source code straight from the workplace and go.
Software developers join the news and media business because there is a lot of interesting high-load work, the competition in the business is fierce, so engineering tends to be frugal and good.
Journalists usually own the copyright to their writings, which by extension applies to software developers working in the same business.
Unfortunately, the pay is below the market, people come, enjoy coding, beef up their resume and github profiles with open source code straight from the workplace and go.
I'd say they're well above the median tech company if there were such a measure. The NYT might be a media company, but it's one that ships constantly, at scale, and over long time periods.
tldr; agile etimation is stupid, don't do it.
this was an enjoyable read/skim. it had at least one funny.
my boss once asked me to track velocity with a small dev team -- we tried half-heartedly, and i had senior folks, who i knew also didn't want to be micromanaged, so i knew we'd get rid of it, and we did after a little while.
"OK, i say we skip the estimates/points nonsense this week, and maybe do some work instead, yeah?"
"Yeah."
and that was that.
got rid of most of 'agile', in fact, and got a lot faster. at least, by my estimation.
zing.
this was an enjoyable read/skim. it had at least one funny.
my boss once asked me to track velocity with a small dev team -- we tried half-heartedly, and i had senior folks, who i knew also didn't want to be micromanaged, so i knew we'd get rid of it, and we did after a little while.
"OK, i say we skip the estimates/points nonsense this week, and maybe do some work instead, yeah?"
"Yeah."
and that was that.
got rid of most of 'agile', in fact, and got a lot faster. at least, by my estimation.
zing.
Obligatory Link to the "Estimates" song by $stdout, its great: https://www.youtube.com/watch?v=sh7A8UChBTI
Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed.
Once I wrote a script to fetch all the relevant data from Jira to figure out whether or story points give better estimates than simply counting up the stories (because of course Jira makes this as hard as possible for you to find out). I went through the channels, discussed it with different people, at every turn I added more info to the report demonstrating the pointlessness of story points, at each turn the data supported my argument stronger and stronger, across all our teams, for sprints going back years. After weeks of discussing it, we kept the story points, because "upper management wants numbers".
Now, I work at a company where we keep things close to the agile manifesto, we adapt as we go, and we aren't forced to play stupid planning poker, and we have twice a week a short sync call (15 minutes).
For as long as I have the choice, I'll not work for a company with Scrum and story point estimations.