Earlier quoted context omitted.
I know what you mean, and in general I try to follow that advice. In the particular case of project management though, I'm frustrated by the huge amount of too-short and contradictory advice floating around on the Internet; adding one more unjustified summary to the pile doesn't help. So I think the extra details are important. And when you have that many details, the tangential expository fluff helps keep it interes…
>So I think the extra details are important. [...] This is also why I didn't summarize everything at the top: that would encourage people to just read the top and stop there. There's an opposite way to look at it: a good summary acts as a "hook" and entices readers to read the rest of 15000 words. I wasn't suggesting you delete the extra details. Instead, the bullet points at the top give the reader a "road map" to t…
An epic treatise on scheduling, bug tracking, and triage
41–50 of 67 posts
Re: An epic treatise on scheduling, bug tracking, and triage
#42Earlier quoted context omitted.
So what? Even though engineers realize that, as long as you're talking abstract points, and not holding me to a deadline, I have no reason to modify my estimate. And even if I -do- modify my estimate, as long as I continue with that new estimation mechanism for some period of time, velocity will change accordingly and the PO can -still- make accurate determinations of when something will be delivered. If I consistent…
You're missing my point. My point is that no story points need to exist. If you want to average the amount of work done over a period of time then just count bugs and stories completed. The Central Limit theorem applies equally well to stories over the long term, so just collect data. Automatic. We add story points, presumably because we don't want to wait to gather enough data on stories, but the neutral position is…
However, it’s hard to make long-range estimates using only many tiny stories/bugs, because you don’t want to break the job down with such granularity for months or years into the future - plans will change by then, and all that design work will have been wasted. That’s what makes big stories useful; you can estimate months of work in a few minutes. But because they’re so big, you can’t treat them all as equal sized.
Re: An epic treatise on scheduling, bug tracking, and triage
#43I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.
Re: An epic treatise on scheduling, bug tracking, and triage
#44Earlier quoted context omitted.
You're missing my point. My point is that no story points need to exist. If you want to average the amount of work done over a period of time then just count bugs and stories completed. The Central Limit theorem applies equally well to stories over the long term, so just collect data. Automatic. We add story points, presumably because we don't want to wait to gather enough data on stories, but the neutral position is…
If you look at the first Central Limit Theorem slide in the original article, it compares story precision vs precision of unestimated bugs. The short answer is that if your stories are big, not estimating them causes more error (weeks or months) than most people are willing to accept. Not so with small tasks (bugs) which average out, as you suggest. However, it’s hard to make long-range estimates using only many tiny…
The problem is not that they're engineers, no one is good at estimating work they've never done before. This is a well known problem in pretty much every single software shop I've ever been in. Teams never deliver what was planned on time, only functional teams cut features for releases. This is not a "win" for estimation.
Re: An epic treatise on scheduling, bug tracking, and triage
#45I found that the more experienced/older I am, the less this happens. We even finished multiple such tasks sooner then was required - of course contributing factor was that deadlines were sane. I somewhat used to have this tendency when I was younger. Experience makes you better at managing time risks. It is actually one issue I have with cookie cutter agile. Everyone is so micromanaged by the system, that they don't get to get experience needed to learn the above.
There are also contributing cultural factors. In many companies, people who stay late last week tend to be praised and rewarded over those who work in predictable speed and kept eye on the deadline from day one (not in my current team). Incentives matter and finishing tasks at the last moment at cost of evenings/weekends makes you a hero.
I personally know people, including leads of agile teams, who believe that last moment desperate effort is somehow necessary. Like you are lazy if you dont. That means there will be last moment effort, whether it was needed or not. So if the team is going to be on time, an additional work is found to be done - or more often possible logical steps to make the deadline are not taken (a feature the customer explicitly said is not necessary is done anyway etc). I wish this would be a joke or exaggeration, but I have seen it multiple times already. While details were each time different, it really did boiled down to techies essentially organizing that desperate effort for themselves.
It does not matter what the process is, how exactly you estimate etc. As long as not doing the responsible thing is rewarded, people will do that.
Re: An epic treatise on scheduling, bug tracking, and triage
#46Earlier quoted context omitted.
So what? Even though engineers realize that, as long as you're talking abstract points, and not holding me to a deadline, I have no reason to modify my estimate. And even if I -do- modify my estimate, as long as I continue with that new estimation mechanism for some period of time, velocity will change accordingly and the PO can -still- make accurate determinations of when something will be delivered. If I consistent…
You're missing my point. My point is that no story points need to exist. If you want to average the amount of work done over a period of time then just count bugs and stories completed. The Central Limit theorem applies equally well to stories over the long term, so just collect data. Automatic. We add story points, presumably because we don't want to wait to gather enough data on stories, but the neutral position is…
We add story points because given consistent incentives, estimates tend to be consistent. Maybe consistently under or consistently over, and obviously there's a bit of wiggle room from estimate to estimate, but they tend to converge quite quickly, and to within a week or two's uncertainty of what we'll have done at any given point within the next six months, and within 6 weeks within the next year. Quite a far cry from not using them.
Meetings? Some, sure; you'd have them anyway just defining what it is you're doing, the additional burden to assign points takes up maybe half an hour per person per week or two. Training to get consistency right? There's no training involved. The hardest thing is to get people accustomed to picking a number, relative to the others. But that's not that hard either; we basically just took the first sprint's stories, organized them into a line (much like his rectangles) going from least to most complex, then discussed where to draw three vertical lines, separating them into four distinct sizes, 3s, 5s, 8s, and 13s. We then made sure the largest didn't feel too large compared with the other 13s (or else it might actually be a 21, just compared to what we had agreed a 13 was, and so we had to split it up), and from there we always had 'reference stories' to decide whether it felt more like a 5 or an 8, say. And while we sometimes differed, we could always hash out why we differed and come to an agreement on exactly how large the story was. Again, per the OP, so long as you are consistent with how you address those discrepancies, your overall estimates will be consistent, and give you predictability.
One half hour per week or two is hardly a huge cost to pay when it gives the business the ability to accurately predict when we'll have something delivered.
I don't care if the argument is convincing. I've seen it work. You're free to do whatever you want; I know what I've seen work, and what I've seen not work. I've yet to find something that works so well.
Re: An epic treatise on scheduling, bug tracking, and triage
#47Earlier quoted context omitted.
You're missing my point. My point is that no story points need to exist. If you want to average the amount of work done over a period of time then just count bugs and stories completed. The Central Limit theorem applies equally well to stories over the long term, so just collect data. Automatic. We add story points, presumably because we don't want to wait to gather enough data on stories, but the neutral position is…
Sure, we could treat all stories as being of a single size and rely on the central limit theorem, but that takes far, far longer to converge. On the order of years, I suspect, not weeks or months, which is what you get out of pointing. "We should have this done sometime between now and 2022" is not a useful metric for a PO. We add story points because given consistent incentives, estimates tend to be consistent. Mayb…
If you just want to throw out anecdotes I'll give you my own. I collected data on all the pointed stories at one previous job for three years and found a negative correlation between story point and time from a story being started to being completed.
Sure, you might claim that it all averages out in the end, except that our velocities were wildly in flux for that entire span as well. But we were just "doing it wrong" right?
Re: An epic treatise on scheduling, bug tracking, and triage
#48Earlier quoted context omitted.
Super interesting points here. You mentioned that the real-world Kanban board forces you to empty slots to make room... I've never seen that in any of the software Kanban-style systems have you? I've played around (in spreadsheets and basic apps) with trying to create systems that scaled available slots to team size as a way to force correct granularity.
No, I've never seen it enforced by tools. Physical (index cards) kanban boards have an implicit space limit though, and this is one of the too-seldom-acknowledged reasons why they work as well as they do. Unfortunately the software clones of physical kanban boards copied the unnecessary part (visual appearance of index cards) and not the necessary part (limited space at each phase).
Re: An epic treatise on scheduling, bug tracking, and triage
#49I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.
I disagree strongly with your take on story points: First, if story points are an indirect measure of time, then the "psychological game" you're playing will be immediately revealed if your engineers are as smart as claimed. There is no reason for me to point something a 2 over a 3 unless you're measuring the time it takes to deliver software based off those measurements. On the opposite end of the spectrum, my confi…
The points can (and should) be assigned before the work arrives. Agile planning is a little more nuanced. There's business valuation (points from business development) which then become stories that are estimated during/over another sprint. The points don't correlate directly to hours because you haven't assigned points or know what resources will be on the estimated sprint. That is the responsibility of the Scrum master to handle. If people are vacationing, sick, replaced or there are new hires, you put a variable time-value on the points. Most importantly, you put a few stories in the current sprint off the top of the queue and pull as time allows. Telling the engineers that "all these stories must be done by the end of the sprint" negates the whole process.
> Finally, I have not seen, and you have not presented, evidence that engineers are good at estimating.
In general, nobody else is capable of coming close. That being said, I've blown up estimates to maximum by inquiring about specific details (what file, function, library, what repo, do you have creds for that, how long are the code reviews, etc) in a majority of tasks because some engineers are good as estimation for specific implementations, otherwise they concede on identified complexity/meta-process. Small, Medium, Large seems like the correct approach.
Re: An epic treatise on scheduling, bug tracking, and triage
#50Earlier quoted context omitted.
The goal is not the problem. The method is not the problem. The problem is the problem. You will have to increase the educational system's budget. You will have to raise taxes. You will have to build more classrooms. You will have to hire more teachers. You will even have to feed the damned kids, and improve their home life. There is no "method" that avoids having to do these things. These are the problems you have t…
I think we agree here, except on definitions. To me, potential "methods" are the list of things you describe: taxes, classrooms, teachers, home life, baseball bats. And also the ones I described: teach to the test, fraudulent scoring. A manager that just says "teachers will be evaluated based on their students' standardized test scores" will get nothing useful, because they did not provide a method, and the teachers…
There is no method for a teacher to solve those problems. It's a systemic issue.