Nicola Sedgwick, 19th September 2018, at @FFSTechConf
Right, so, next up, we have Nicola with For Fuck's Sake, They're Only Story Points. [Applause].
NICOLA:
I'm afraid I have notes on my phone for speaking throughout this. I was meant to be all prepared, and the contract I was on was ending at the end of August, but the contract was extended and launch day is imminent, so the prep kind of went out the window.
I'm going to start off by getting a few rants off my chest, the kind of thing that inspired why I put this tweet up in the first place.
We're meant to be talking about the story. What matters is the story - what we are trying to build, what we are trying to solve. Who gives a sod about the number? The problem isn't whether it's a three or a five, the problem is why one person thinks it's a three, one person thinks it is 21 and one person isn't speaking. Already there are disagreements between us - there’s a lack of understanding. I've forgotten the phrase that John used earlier already - er, moral neutrality? Who doesn't care and is sat there thinking “it doesn't matter what points I give it, I'm just doing what I'm told”? Who actually cares about what is being built and why, where the problems are, how it all interacts?
Let's start off with a little bit of maths. My daughter is four. She started school the other week. She's currently learning one plus one equals two, two plus two equals four. At some point in a few years, she's going to learn that's not true. At some point, we learn that two plus two has a multitude of answers depending on your context. So somewhere around the point you do fractions, you learn two plus two can equal five - it depends on your rounding. And then, at some point, depending on who you hang out with at school, two plus two equals a fish. [Applause]. [Laughter]. I wonder how many project managers would like me to add up points and say, "That will be a fish."? What does that mean for delivery? Woo, go fishing! So, we learn these tricks through school, and then we are working in Agile tech project teams and going back to the simple maths we learned in reception class assuming that numbers add up and mean something. They don’t.
I was late getting here this morning because I added up my numbers. I had a bus from my home to the station, train from Reading to Paddington, tube from Paddington to Moorgate, I added up the numbers, and then used my own personal equation - I left leeway for any of those bits to have delays. My walking is delayed by whoever gets in my way! I didn't leave enough leeway; I was still late! Equations don't work. The numbers don't work. The conversations around them is what we want to try and aim at.
Who knows the Fibonacci sequence? Who knows and loves it? Starts with a one. What is the next number? [Audience shout out answers]. Yes, it is not that! [Laughter]. That is not Fibonacci. [Pointing at slide showing “0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?”] I have a physics degree and a maths background. That is not Fibonacci! There is no question mark. There is no ... . [Laughter]. I’m quite proud of my physics degree - I wasn't allowed to put question marks! There is no cup of damned tea or coffee, and it's not a binary choice on a cup. I hate them both. Where's the hot chocolate? It's this sort of thing. It's seriously sodding depressing. And you take this wonderful idea of people wanting to stop others adding up numbers, we will stop them saying four is half an eight by making the numbers in use be not easily divisible. Fibonacci can do this for us. It is a pretty spiral. We can do this. Then humans get in the way again and fudge the numbers! Someone on the opposite end receiving these numbers desperately tries to work them back into units of time, because people are always going to ask when something's going to be delivered. For some obscure reason, the people giving those answers seem absolutely incapable of saying, "I don't know, but this is how we are doing so far".
So, normally, at the point of discussing why Fibonacci doesn't work, someone comes up with a bright idea of, "It's just T-shirt sizing". [Laughter] [Points at image on screen] That is the same sized shirt on six different women. [Laughter]. Top left, and top middle - those two women technically have the same sized bodies by the equation that calculates clothing sizes using measurements of the body. They don't look the same - the models bodies are different. Why do we keep coming back to an equation of what a point means? The number means nothing. The conversation means everything.
So a family member asked what I was going to rant about. A family member was interested in me ranting. Briefly! [Laughter]. So I said it's about story points. For some bizarre reason, through completely separate routes, we've both ended up working in tech in Agile teams. I said it's about story points and a rant how they are misused. Their response was, "Oh, they're useless." We were in agreement - this is a good place to be; this never happens! And they followed it up with, "I never go to those meetings, they're useless". Pardon? “That's for the developers. I'm not involved in the build”. I queried wouldn’t the developers want to talk to them? They might want answers in order to do their sizing of how long something's going to take, how complex the problem is. The response: “That's for them to talk about. They've got the spec.” This isn't going to end well, is it! Because of story points, because in their company, the points are equated to time, because they came out with the phrase of “T-shirt sizing”, and apparently medium T-shirt is a day's work, they don't see these meetings as beneficial to them and came out with a stock phrase of, "Well, there are too many meetings". If there are too many meetings and they're not useful, maybe the problem is you're doing the meetings badly. Maybe you're using the tools badly, and you're creating segregation in your team and justifying it all by saying it is the tool and the points that are the problem. That's when the phone call ended! [Laughter]. We will find another thing to disagree about another time.
So, for me, - and this is where I may have misunderstood this conference slightly. I've come up with a few different of ideas of how things can get better. Feel free to dissent in the Q&A afterwards.
For me, story points are more like abstract art, so, depending on my mood, this is either a pretty cityscape in the desert or a desert car race heading straight at me. [Points at artwork on slide] Everyone else sees something different and other people go “oh, a load of splodges on a canvas”. That is what the two, three, eight points mean. They mean different things to different people. You get four people together, their definition of what points mean between them is different to another group. You change a member of a team, you change your story-point meanings, you change what your baseline is, and... Something that I find quite messy in the tech world is something that with a physics and a maths background is innate for me, is that if we change anything in the experiment, then we redo the baseline. You have a control experiment alongside. You re-check, you re-calibrate. In mechanical engineering, you recalibrate. We don't do that in tech. It's a new project, it's a new problem, it is a new stakeholder, it's a new client, it is a new team (we mix up the teams so people don't get siloed). That messes everything up - the dynamics, the way you work together, the conversations you have. We don't come back to these things to re-assess. I've got a slightly crazy belief that we're all, at heart, rational humans capable of having conversations with each other. This may be wrong! Sorry! [Laughter]. But I've got a vague belief we want to work together. We want to work with our skills, we want to improve. It's quite nice to produce things that we see people using out in the world all nice and ethically.
So, how do you fix points? I'm not going to tar teams with all the same brush. I've been on some teams where story pointing exercises are seamless. That's a three, that one’s a five, and it becomes about what is a five versus an eight, rather than massive disagreements. If that is the extent of your problem, is it a five or an eight - is that really big a difference? It's a story, get on with it.
There's a hashtag going around on Twitter, #noestimates, “No estimates” people are saying. Via that, I came across a new story-pointing deck [Showed deck from https://estimation.lunarlogic.io/ on a slide]. It is either a story - that is your ‘1’ - it is too fucking big to be a story (‘TFB’), or there's no fucking clue (‘NFC’)! [Laughter]. Three cards. The person who introduced this to me made a sideways comment that it's quite hard to put your branding on a pack of cards when they only have three cards in them. Cynical. Maybe that's the case. But maybe it’s that simple. Maybe it's a story that can be worked on, or it is not and you can break it down further. The thing is, the person telling me this, and the person advocating it, defined a story as something that can be built in three days. [Laughter]. So the problem of the equations linking stories to time and enabling reporting - it's not gone away.
So, I don't think there's anyone here that's ever worked with me before. There are people that have been to conferences with me, and they know my slightly warped sense of humour. I tend to get a reputation of having off-the-wall ideas, so, here's a couple of them. [Laughter]. Where you have a team that works together - create a team palette. [Points at slide with a Pantone colour palette] The colours mean something to your team. Maybe grey is ‘murky and doubtful’, maybe there's a nice black meaning ‘this is stormy, do not approach this’. Maybe pink means ‘this is going to be fun and there is new tech that we can use while we do this one’. For the crazy idiots that want to count beans and desperately want to report, then every single Pantone colour has a number, and it's unique and there's not necessarily an obvious increase in order. Someone will come up with an equation. They will keep themselves happy, and the estimates will still be wrong, the delivery dates will still be wrong, but they will be happy they can do something with these estimates. I kind of like making people happy, that's why I work in tech, to build stuff.
How many people have ever sent a text message, or a WhatsApp, or whatever, that purely consisted of emojis? Was there any communication misunderstanding on receipt of that message, or receipt of the reply? [Laughter]. We use emojis to communicate. I would actually love to put a little crying cat emoji against a story just to express my feelings. I would absolutely love it if I could see a story that had my crying cat emoji, someone else's poop emoji, and the dev that loves living on the edge has put a little devil-horned emoji on it. To me, that gives a nice picture of how that story is going to turn out. But how do you put that on Jira? So I will end by saying fuck Jira and let someone else rant! [Laughter]. [Applause].
FLOOR - H->> I loved that, and I 100 percent - I'm H. I 100 percent agree. I'm currently on a team where my sort of manager sort of person is very into the whole pointing system. And then I had a wonderful chat with one of them where I basically went, "Would you trust a weather forecast that only had 26 points in a year, that you only had 26 measurement metrics in a year to say what the weather is going to be like the following year." He said no, I wouldn't trust that. Why do we do it for story points. Why only 26 points -- drove me nuts. They woke up and went back to Jira.
NICOLA: They don't work with weather it doesn't impact them. They don't care. It's the weather people's problem, and they get it right so often(!).
P-: I'm P-l. This isn’t a question but an uninvited rant of my own, really.
NICOLA: Go for it.
P-: I couldn't agree more that stories are the basis for a conversation. Conversation is absolutely the most important thing about building software, but when did we ever get so afraid that we stopped being able to talk about time? I think too fucking big and no fucking clue are valuable to say, and if it's too fucking big, break it down a bit, and no clue, how about a conversation about what we don't know? But sometimes we can say “I think it will take three days” and it takes about three days. I'm amazed to see, never seen this before, that you can get decks of cards with pseudo Fibonacci sequences on them. When did that become a thing that developers needed, wanted, or were not embarrassed to actually pick up? You know, we build software, sometimes, it is hugely unique, sometimes, the context is brand new, but that still doesn't mean that you can't have a guess, have a think about what is might take. It seems to me the big issue, and I've followed the tag with a lot of interest, it seems to be what people then do with those numbers, and to John's point about unionisation, if we unionise about anything soon, what I would like to do is remove the idea that these numbers are a promise, or a commitment - these numbers are not a promise or a commitment, it's us understanding better what it is we're about to tackle, but there is absolutely nothing wrong with looking at something and going, "I think that's a couple of days' work."
NICOLA: I've done that before as well. I used to do a lot of freelance test work. I would get a lot of agency clients. We've got a microsite, a competition site, can you give us a quote for how long the testing's going to take. My follow-up question is, "How many browsers do you want covered? What is your client's coverage expectation? What is their budget and priority points?" I can generally give a reference point. So ten browsers for a two-page microsite with a simple "submit your email address form" that was a day's worth of testing. It was known I had done it before. I had done similar things. They are an agency that did the same kind of thing but a different look and feel for different clients. What I find in the places I work that do more complicated things is that the people in the middle often don't have the humility to stand up and say, "We don't know" or, "This is in flux," or, "This is the number and here are the caveats" or “If all of this lines up, it will probably be ready in six months but if any of these go wrong, it is two years”. I've been in a contract where the people in the ‘middle’ disappeared (for various reasons), and I was standing in front of the senior management saying it like it is, because who am I? I'm Nicola, I often work as a tester, I'm in the dev team. Why should I not tell them the truth about what is going on? I got a lot of respect in turn. There's this whole middle layer of crap trying to report on what we do and gloss it up. It breeds mistrust, and you get into the, "I don't trust your figures, they have to be more accurate the next time, and, if you don't deliver on time, I trust you less." Yeah, unionisation, reformation. I have this crazy idea of a CHEAT system to revolutionise software development with Conscious Communication, Holistic viewpoints across systems, get everyone involved that needs to be involved, not just little silos; be Ethical; Agnostic - do not hunker down with ‘only Java can do this’, maybe there's something else that can work and maybe it is not a tech solution; and, Transparency. If you have all five of them, the mistrust around the estimates goes away.
FLOOR - M->> Hi, it is M-. This, constant conversion of story points to time is because of a demand and a need to come up with time estimates because people do need these things. What is a better way to do this to get us away from story points?
NICOLA: Get at the people that think they need time. What they normally need is information. They need to understand and trust the information, because quite often, where there are people saying ‘we want feature X by spring’, no-one's asking them ‘why spring?’. Maybe it needs to be shown at a board meeting in order get the next round of investment, maybe it’s been contractually promised as part of a government tender. Maybe it's just that they asked because if they don't set a date then they never get anything, and just get left on the bottom of the pile. Sometimes I want to clear out everyone in the middle and just get to the people at the top. Apparently, that's a bit subversive.
FLOOR - J-: I'm J-. I've worked in two very different organisations. I worked for an organisation which made you estimate to the half day, not even story points. They literally wanted a time something would take which led to me finding a Jira which had been estimated at 115 and a half days. [Laughter]. That estimate was not met.
NICOLA: Under? It was under?
J-: No! They were never under. But, you know, this ludicrous system. To where, you know, the Jira had a million lines on them saying, "This is exactly - these are the lines of code that will be written which led - which led to people saying why aren't we writing the lines of code. Led to things like this feature is broken, Jira fix the feature. No estimates given, engineers given carte blanche to say we're not saying how long it will take. We're saying it will be finished -
NICOLA: It works on my machine.
J-: Yes, absolutely. My PR went green, therefore, it is fine. And what you find in the other organisation to answer the question that was answered before is that you have to talk to the people who are going to be using the software, or at least the people who are representing the people who are going to be using the software, to find out what they actually mean. It's not just a case of story-pointing within the developer community and bringing that, it's a case of going, "Well, why didn't that - not only will how long this take?" That is a sort of side question, let's put it to one side. "What do you actually want? What are you actually doing here?" "You've come to me with a solution saying when you press this button, it turns the screen blue." Your question is, "Why do you need that? What is the point of it?" Not following orders doesn't just become an ethical question but is there actually a point to that? Is it efficient? Is it the best way of solving the problem you have? What is the problem you have? And so on.
NICOLA: And you get into a whole other realm of story-mapping at that point. It is a problem that people ask for what they think they can get or what they know that they can describe, not what they need.
J-: Absolutely. What you need are story points are a side irrelevance issue which is about trying to get information out of between developers and the people who are using the software, whereas actually what needs to happen is that those two groups need to sit down and have a conversation, and you find that story points become less and less relevant, and estimation becomes less and less relevant.
NICOLA: You can also sometimes have fun. I have a hobby background as a re-enactor. Occasional when the conversations don't happen, I mention that I should bring in swords and spears to liven up the conversation!
FLOOR - L-: My name is -. I'm so glad this subject came up. I'm so happy for FFS for choosing it, and thank you for putting it forward. I am so sorry - I was an innocent ... [Laughter]. I was an innocent attendee at a training course that taught me how to do story-pointing, and the enthusiasm that I was given for doing it, and the reason why, and I started off my career as teaching story-pointing to my teams, and having them understand oh, they will get it after a while, and, then after a while, I thought, "This is fucking useless!" [Laughter]. We are wasting so much time. Why can't we just talk about the fucking stories and throw away the points? That's my rant for your rant! [Applause].
FLOOR - D-: My name is D-. So I think here, it comes down to broken delivery models, people being unable to think in increments. Let's do 700 stories, and then release them into production, as opposed to put a picture of a cat on the internet, and then release that and increment on it. It's broken, you know, morals from between, as you already kind - unfortunately, all my points have been amazingly covered already. But it's to do with broken models of directors sitting in a board meeting saying, "I want this thing and you don't get your bonus unless you lie to me and tell me I will get it." It's to do with this cottage industry, and complex Agile model of a delivery model, safe, and all that kind of nonsense, just that it breeds, just training courses, and stuff, and everything around it, it's just kind of getting away from just delivering the fucking software, for Christ's sake. Just something that you can see, yeah, I completely agree with everything you said.
NICOLA: it's the irony that all those models, someone at some point came up with them to try and help us, and then, I don't know, maybe they got asked too many questions about how it works, so they came up with other rules to kind of clarify their help, and then they started teaching them, and, I've run training sessions where people ask awkward questions. You kind of flesh it out a bit more because you want to help people, and then there's certifications and frameworks, and corporations, and suddenly, it's not helpful!
D-: I think it might have started with branded story cards! [Laughter].
D-: So, yeah, I would like to share a bit of a novel experience that I have had recently for the past six months, I've been working with a team who are stable, working to a stable goal, self-organising, and autonomous, and I've been watching the story points thing evolve over that time. I was worried, because our velocity was going down. People were just estimating a bit lower, so, that was a false indicator there. As the team have evolved, you know, we've seen story points become less and less relevant, but I do think it is really important the developers still go out there and say, "This is how much we think we can deliver. This is what we think we can achieve within a time frame." That is a really important part of motivating and bringing a team together, and the commitment is a really important psychological hack, but I would go further than saying fuck story points, I would say fuck stories. Work out what you're trying to do, work out what you need to do to get there and actually the team with a little bit of experience has actually got way better at doing, "This is what we are going to achieve this sprint, let's work out how we're going to achieve it" rather than the scrum backlog management which encourages you to do it in the opposite direction.
NICOLA: Absolutely.
FLOOR - J-: Hi, J-. I want to remind people a rant later that Dom is doing later about FFS Just Talk To each Other. The thing that -
NICOLA: That was my other tweet, the Dom one!
FLOOR: For fuck's sake, you can't constrain three sides of triangle you've got scope, budget, and time. If date is important, you can't hit it, you've got to compromise on something. So, you know, you can put constraints in, you can hard-code stuff, there's lots of stuff you can do apart from just dropping features, but what is the cost of not doing something is the question you've got to ask yourself?