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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I think you may be misinterpreting the comment. Parent is simply pointing out that most of the relevant skill in programming comes from on the job training. That's hard to disagree with.
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.
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:
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
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.
I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows what else (e.g occasional scrum of scrums for a feature nobody understands, across teams and domains, with around a 100 people, with breakout rooms and presentations of all the teams' "commitments").
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.
> 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.
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.
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.
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'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 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?
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.
> 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.
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.
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.
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.
> 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.
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.
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"?
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.
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.
87 comments
[ 3.1 ms ] story [ 150 ms ] threadLarge 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.
<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.
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.
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.
I think most software engineers know this. In my experience, the problem is that management doesn't.
Ideally, most stories should be 3 or 5 pointers.
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.
Neither is right or wrong, just different.
Turns out it's from their dev blog and it's an interesting read.
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.
In comparison, Jira's not so bad...
As with everything, a purposeful balance is best imo.
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/
"You can have any color car you like, as long as it's black."
- Henry Ford
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.
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.
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.
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.
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.
Other things just aren't valued.
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.
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.
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.
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).
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.
This is obvious BS. Not sure why, though . . .
Because the author complains a lot but really doesn't exactly say . . .
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.
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 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’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 ...
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.
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.
On the other hand, a minimum amount of time required for a project seems to be well accepted by project managers and others.
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.
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.
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 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.
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.
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'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?
> 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.
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.
* 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.
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.
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.
> 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.
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.
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.
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.
Who's doing such well known repetitive tasks that they also need estimation for?
Circular black hole imo.
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.