
An epic treatise on scheduling, bug tracking, and triage - lostdog
http://apenwarr.ca/log/?m=201712
======
apenwarr
I’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. 

~~~
po
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. 

~~~
apenwarr
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). 

~~~
WorldMaker
Rally lets you set card limits in each column, though in practice that always
seemed too easy to change (just add a couple more to the limit; just
"temporarily" turn off the limit) to be entirely beneficial. 

------
markphip
Interesting article, I have a few comments/questions

Story points - there is a lot in theory I like about these and you hit on
those points.  But in practice where my teams have struggled is still in the
definition of a point.  People understand the relative sizing concept but they
still want a definition of what one point means and that invariably winds up
being some kind of a time unit, which means all points get thought of in time
units.  What techniques have you used to solve this problem? 

Defects - some good points were made but you never really discussed how these
are managed as work.  Stories and defects are getting worked on at the same
time, but how exactly?  Are defects just lumped in with stories and the PM
prioritizes them?  I do not think so, but you are not clear in this area.  If a
PM prioritizes a story but the team spends all of its time resolving defects
then how is value being delivered as expected?  You seem to have left this out
completely, or I missed it. 

Finally, also on defects, while your points on not estimating them makes some
sense, someone has to decide what to work on, and generally you need some idea
how long things will take to make that decision.  Even in your wording, you
acknowledge some defects take a long time to fix, where as others are super-
quick and in the end they all average out.  Still, someone in the organization
still cares about dates and delivery.  It made a lot of sense to me where you
indicated that the story point estimate can be valuable to the PM in terms of
prioritizing.  When they see a story with a high estimate that might cause them
to lower its priority compared to other stories they can get delivered
quicker.  But seemingly defect fixing would have to factor into this somewhere
too, and then wouldn't the same concept apply?  If defects are not estimated,
how can the time it will take to resolve the defect inform the decision making
process? 

~~~
lliamander
I actually reject the idea of story points as a unit-less number, mostly
because people can't help but think about them in terms of time anyway
(whether they want to or not) [1]. 

Rather, I like to use a discrete list of story point values as scalar value
that represents a probability distribution for how long the task might take. 
As the story point gets bigger, not only does the mean time get bigger, but
the variance grows as well. 

For example, a 1 is 2-4 hours, but a 13 is 2-3 weeks, and a 40 is 1-2 months. 
The idea is that not only do more complex tasks take more time, but the
precision of our estimates goes down. 

This makes engineers happy because they get to be more honest about estimates,
and it makes managers happy because they only have to deal with one number. 

[1] Unit-less measures might be easier in an environment that is more
concerned with true productivity than with deadlines, but that is not most
environments. 

~~~
markphip
Thanks and interesting.  If you have written up your full system anywhere I
would be interested to read more. 

~~~
lliamander
In terms of mapping story points to time ranges, here's the full list:

1 point -> 2-4 hours

2 points -> 4-8 hours (1 day or less)

3 points -> 1-2 days

5 points -> 3-5 days (up to one week)

8 points -> 5-9 days (up to one two-week sprint[0])

13 points -> 2-3 weeks (1-1.5 sprints)

20 points -> 3-4 weeks (up to two sprints)

40 points -> 1-2 months

Anything beyond 40 needs to be aggressively analyzed broken down into steps,
even if those steps are not deliverable features per se. 

[0]For a two-week sprint, you have to account for at least one day each sprint
for demos, retrospective, and planning.  Thus, you have at most 9 days for
implementation and testing. 

EDIT: Fixed formatting. 

------
peterwwillis
> What doesn't work is deciding when you're going to get there. 

That would be an ETA, which is quite useful in many cases. 

> Or telling salespeople they need to sell 10% more next quarter. 

That's a minimum quota.  Also useful. 

> Or telling school teachers they need to improve their standardized test
> scores. 

Which is not so much a 'goal' as it is a response to the need for kids to
actually learn information.  It's a goal in the sense that "you should be doing
your job to a minimum degree of proficiency" is a goal. 

> Or telling engineers they need to launch their project at Whatever
> Conference (and not a day sooner or a day later). 

Which is absolutely an arbitrary goal that doesn't have anything to do with
the product, but is also good business sense. 

Sometimes you need stupid goals. 

~~~
apenwarr
What all these wrong-goal examples have in common is that people have tried
them over and over, and they never work the way you want.  The reason they
never work is that they don't specify the method.  As one of my favourite
Deming quotes says, "If you can accomplish a [numerical quality/goal] goal
without a [new] method, then why were you not doing it last year?  There is
only one possible answer: you were goofing off." 

What ends up happening is that people will cheat the system so they can hit
the target you enforced, while sacrificing some other critical thing you
forgot to enforce.  In the educational system, for example, what happens is
"teach to the test," which causes improved standardized test scores at the
expense of actually learning things.  And, of course, you get schools that
outright cheat when scoring the tests:
[https://www.washingtonpost.com/news/answer-
sheet/wp/2015/04/...](https://www.washingtonpost.com/news/answer-
sheet/wp/2015/04/01/how-and-why-convicted-atlanta-teachers-cheated-on-
standardized-tests/)

Re: ETAs, those are predictions, not goals.  Predictions are good.  Most of the
article is about the difference between the two. 

~~~
peterwwillis
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 to solve to reach the intended goal.  How you go about
solving these problems _does not matter_. 

Use whatever method you want.  Sweet talk them.  Bribe them.  Hire a guy named
Vito with a baseball bat.  The method doesn't matter. _ Just solve the
problems._ 

~~~
apenwarr
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 aren't empowered to solve their problems in
a productive way. 

~~~
peterwwillis
> 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

There is no method for a teacher to solve those problems.  It's a systemic
issue. 

~~~
amw
He didn't say anything that was contrary to that.  Note that it's the "manager"
that didn't "provide a method" in his framing, and note that "manager" is a
shorthand for "the teacher's boss, the school board that created the policies
the teacher's boss follows, the federal/state governing bodies that created
the legislation that governs the school board's decisions, etc etc"

------
watwut
"They're sure they can get done in that amount of time, so they take it easy
for the first half.  Then they get progressively more panicked as the deadline
approaches, and they're late anyway, and/or you ship on time ..."

I 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. 

------
vodkaPong
I really enjoyed reading this, despite its length!  It makes some great points
about scheduling that resonated with me, backed up by interesting thought
experiments. 

------
PaulRobinson
TL;DR: Agile is silly but has some lessons to teach.  Most people do it wrong
though.  Make decisions early and stick to them.  Talk about effort not time. 
Make stories about users.  Treat bugs differently to stories (they are on
average all the same size, are written from a different perspective, etc.). 
Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about
deadlines, ever. 

~~~
pjc50
So .. what is the _business_ substitute for deadlines?  Unless you're genuinely
a startup with unlimited funding and total freedom, eventually people are
going to ask the question "so what are you going to deliver and when?" 

~~~
agentultra
That is often the first question I get asked when trying to explain these
concepts to business owners. 

My answer is that you can plan for work to be done on a deadline but you can't
negotiate when it will be done with the people doing the work.  It's going to
take as long as it takes.  It's poor management that sets unrealistic
expectations and demands results. 

You can plan for work by using data.  You get data by tracking effort estimated
versus completed and triaging bugs.  You prioritize goals instead of setting
deadlines.  You measure and refine. 

It sounds counter-intuitive to business people who think in terms of, _I just
sold customer X the product and they need it delivered by Y so that we can get
the team paid by Z_.  This is where poor management decisions can sink your
team.  If _Y_ is decided by the sales or management team with the customer and
they didn't consult their engineering team... then they're working on another
planet.  The goal of processes like this are not to eliminate _Y_ but to set
reasonable expectations and objectives. 

As I like to remind my business owners: you can have something that works --
it may not be the whole kit -- or you can have nothing at all.  Winning is
about prioritizing objectives. 

One book I've read recently that taught me a lot about management is _Extreme
Ownership_ [0].  I think there's a lot of cross-over from this book into Agile
methodologies that I think non-technical stakeholders can really understand. 

[0] [https://www.goodreads.com/book/show/23848190-extreme-
ownersh...](https://www.goodreads.com/book/show/23848190-extreme-ownership)

~~~
jasode
_> It's going to take as long as it takes. [...]  it may not be the whole kit _

If I'm interpreting that fragment right, your essay is treating "programmers
development time" as a fixed rate of progress (the _" 9 women can't have a
baby in 1 month"_ meme) so one answer to meet a deadline is to _remove
features_ until the deadline can be met. 

~~~
agentultra
Precisely.