Category: Scrum

How much should you plan?

On By JPIn Planning, ScrumLeave a comment

There is a mass of literature about how, how much, and how often teams should plan. Most people recognise that we should avoid the extremes of overly heavy processes (the Sin of Waterfall) and the anarchy of pseudo-Agile, which often manifests itself as “hey, Agile means you don’t have to write anything down!”.

The most commonly used pattern that is meant to guide teams between these two extremes is that of Scrum, which mandates a single, two-hour Sprint Planning meeting, once per sprint, which produces in one go the correct amount of planned work for the whole team, which would be 100 man-days of work for a 10-person team (all of these figures presume a two-week length sprint).

In practice there is a large amount of unavoidable variability in the execution of a block of 100 man-days of effort, and work is constantly being discovered or reprioritised during the course of the sprint, meaning that the output of a single Sprint Planning meeting at sprint start is often wholly inadequate for the rest of the iteration.

The better, alternative approach is to apply to planning the same principles that almost all software development teams already apply to deploying – that it is best done little and often. You need to be able to decide on any given day whether you have planned enough, or need to plan some more (possibly that very day), and the good news is that a well-functioning Agile Board is constantly giving you this information, if you know where to look.

The key concept is that there is a status – in software development teams usually called Ready for Dev, aka Ready to Start – which represents a buffer state between the end of the planning/preparation process, and before the start of the delivery/execution phase. This column holds your stock of planned work.

agile-board-ready-for-dev

So how much stock should you keep? Well, it is possible to plan too much, and to plan too little, and between those extremes lies the Goldilocks Zone where you have planned the right amount.

The problem with planning too little – ie there is a small number, or even zero tickets in Ready for Dev – is hopefully clear; the delivery part of your pipeline will be starved of fuel, and will grind to a halt. Yes, you can do some emergency planning there and then, but this is an inefficient and stressful way to work.

Less obviously, it is also possible to plan too much. Perhaps it is tempting to get 100 tickets to Ready for Dev, and then you won’t have to do any more planning for six months? The problem here is that planning has a shelf-life; all plans are predicated on assumptions about the state of the overall codebase, the product and the company at the moment delivery starts. If the gap between planning and execution is small, these assumptions are more likely to be correct.

But if that gap is large – say you plan a piece of work now but don’t start it for a year – it’s very likely to need replanning from scratch (eg because the tech landscape has completely changed) or to be thrown away entirely (eg because that feature is no longer a priority). So you invested a large amount of time and effort in that huge planning exercise, and in the end most of it was waste – that is the consequence of planning too much.

So how do we get to the Goldilocks Zone where we constantly have the right amount planned? This amount is contextual – it varies for every team – but the principles are universal.

Begin by picking an approximate period of time for which you want a stock of already-planned tickets. You might for example want “planning” to be 2-3 days ahead of “delivery”, meaning that if you stopped all planning activities immediately, it would be 2-3 days before Ready for Dev runs out of tickets.

How do you know what period of time is appropriate to pick? That depends on the availability of the people who do the planning. If the people required for planning are all highly available (ideally, co-located) people who are dedicated to this one team, they should be able to switch to planning activities at very short notice (ie they can plan on the same day a deficit is noted). This setup requires a smaller buffer of planned work. Different setups need a bigger buffer to make up for the extra time it will take to get new planning scheduled.

This period of time then needs to be translated into a desired number of planned tickets. Here the main factor is team throughput; the quicker your team gets through tickets, the more you need in your Ready for Dev buffer, so if a team gets through 3 tickets a day and you want a 3-day buffer, that’s 9 tickets.

This calculation works fine if your team is very cross-functional, meaning anybody can pick up any ticket, but if you have specialists on the team who can only work on specific kinds of tickets, you will need to factor that in, and ensure that each separate specialism has enough of their kind of tickets in Ready for Dev.

Having thus calculated an approximate target for ‘planned tickets’, the deciding factor – as ever – is experience. If you observe a team’s Agile Board regularly over a small number of weeks, it should become clear what the right number of tickets in Ready for Dev is for that team.

Teams applying this method may end up cancelling all regular planning sessions; instead they decide during each morning’s Stand-up meeting whether or not a planning session is needed for later that day. This is a truly Lean/Agile team, where processes have become highly dynamic and responsive, and ‘rolling wave’ planning has been truly implemented.

Rolling wave planning can apply at the strategic level too. Just as a delivery team can get its planning down to a snappy half-hour meeting every other day or so, a company can get its detailed roadmap planning down from six-monthly or quarterly (which is often regarded as a triumph) down to something closer to a monthly rolling wave. The same preconditions – an accurate portfolio-level Agile Board, and good availability from the planning resources – are of course also needed to achieve this goal, which produces the same rewards of more responsiveness and less waste.

Agile board design example – columns part 1 (getting stuff ready)

On By JPIn Agile Boards, ScrumLeave a comment

An Agile Board is a model of a team’s workflow, the series of steps its work goes through from conception to completion. The first thing you have to get right (or rightish; boards will evolve over time) is the columns you use to represent those steps. In a previous article I discussed the background to such decisions, and in this one I will run through a hypothetical example.

One way to conceptualise a software development team is as a machine for converting ideas into fully tested working code in production that benefits real users of the system. That is, the input to this machine is ‘an Idea’ (=the very first step), and the ultimate output is ‘provably working code in production’ (=‘Done’, the very last step). Thus we have bounded the beginning and end of our workflow – now we just need to work out the stuff in the middle.

Idea ? ? ? ? ? ? Done

Somewhere in the middle of this sits a critical state called ‘Ready for Dev’ (or R4D for short). This means that a ticket is fit for coding to begin on it, and it might take a lot of work to get an idea to that point. It neatly divides our total workflow into two; steps prior to R4D are about getting tickets ready, and the steps after that are about delivering that work. For reasons of length, this article will be about that first half, and a separate article will cover the delivery steps.

getting tickets ready delivering
Idea ? ? ? R4D bla bla bla Done

So let’s flesh out the steps between ‘Idea’ and ‘R4D’. What happens after you’ve had an idea? Typically there are vastly more ideas (=potential work) than there is capacity to implement them, which means that the next step after ‘having an idea’ is to pool that idea with all the other candidate ideas and do a ruthless selection of the worthier ones. The less worthy either get filed as ‘maybe do later’ or are thrown away. We need to represent this in our workflow with one or more steps that represent grouping / de-duping / trashing / prioritising the candidate ideas, a sequence that will be familiar to anyone who has organised a brainstorming session.

An Agile Board is a simplified model of reality, and it is possible to represent all these idea-processing activities that lead up to a prioritisation decision in just a single step on the Agile Board. This step might be called ‘Prioritisation’, but I usually call it ‘Triaging’, after the parallel process that happens in medical emergency units. The intricacies of Triaging will be covered in more detail here; for now it is sufficient to note the following:

  • Triaging is synonymous with quick prioritisation
  • you can only prioritise after you’ve done a minimum of grouping and de-duping (if a new ticket is a duplicate of an existing one, you just throw it away)
  • the implementation of a ‘quick prioritisation’ decision in a tech team is to have slotted the new ticket into (roughly) its correct place in the ordered backlog of work for the team. When you’ve done that, you’ve finished Triaging.

The amount of information needed to triage varies massively from from case-to-case; sometimes a single bullet point might be enough, at other times considerable business and/or technical analysis might be required to make even basic judgements about the worthiness of an idea, and you have to put off Triaging until that information has been supplied. But whatever that minimum fleshing out is, in an optimally efficient workflow, that’s all you will have done at this stage.

That is because the result of a triage decision might be to do the work much later (potentially changing the spec considerably), or even not to do it at all, so any work invested up to the triage decision is potentially pure waste, and must therefore be kept to the minimum; limited resources should be focused on work which will definitely not be wasted.

getting tickets ready delivering
Idea Triaging ? ? R4D bla… Done

The timing of the next step depends on how high or low a ticket has been triaged. If fairly high up the backlog, the next step may follow immediately. If low down, it may take a while, or even never happen at all. What is that next step, then? Since triaging often (correctly) happens on the basis of relatively little detail, now we have to flesh out the work in enough detail for efficient delivery. I often call this step ‘Ticket Prep’, and if teams have a role of Business Analyst, this step typically consumes a lot of their time.

How much detail is ‘enough’? Well, it might be adding a second bullet point. Or it might be large amounts of work involving a ton of people. It’s completely contextual, and depends on the team, the work itself, and the project / programme / organisation of which it is part. You can get ‘Ticket Prep’ wrong by adding too much or too little detail. Too much detail, the Waterfall Fault, can be a waste of effort – the future is uncertain and some stuff needs to be figured out in real time as it’s being built. But too little detail, the Agile=chaos fault, can also lead to waste – leaving the downstream people to frantically guess as to what’s the work is really about right in the midst of trying to deliver the bloody thing.

‘Ticket Prep’ is a kind of planning, and the idea that here is a sweet spot of how much of it to do up front applies to all kinds of planning. Mike Cohn popularised a graphical representation of this, the planning curve of diminishing returns. The sweet spot gives you decent reward for a reasonable amount of upfront effort.

planning-curve

Every team must find that sweet spot for themselves by an empirical process of trial and error. There are some tickets in some teams that must be specified up-front in pixel-perfect detail. There are other tickets in other teams at other times where to do so is madness, and the decision is multi-factorial. The easier it is to change the work later, the less crucial it is to specify every detail up front. How the team works together is also relevant; in strict BDD there needs to be a failing acceptance test before production code starts, and that requires quite strict definitions. The more developer-UXer pairs work together at the same screen during delivery, the less you need to specify up front. And so on.

Sometimes this single step called ‘Ticket Prep’ wraps a multi-faceted set of tasks that requires much expertise and many people. Sub-teams such as UX and Architecture may be extensively involved, and the assets they generate (eg architecture diagrams, wireframes, mockups etc) may be considered prerequisites a ticket to be R4D. These assets typically go through their own sub-processes of creation, reviewing and sign-off, and ‘Ticket Prep’ is sometimes broken down into sub-steps to take make this more visible on the Agile Board. But for this example, let’s keep all that under just the one step.

getting tickets ready delivering
Idea Triaging Ticket Prep ? R4D bla… Done

So surely, at the end of ‘Ticket Prep’, a ticket is ‘Ready for Dev’, right?

Well, maybe. You’d certainly hope so. Maybe the BA (or whoever) who wrote the ticket thinks it is. But getting this right is too important to gamble on; a team needs to check that a ticket really is R4D before it is declared such, otherwise you are potentially seriously messing up the delivery phase, and the lives of all your colleagues who will work on the ticket downstream. Every Dev and QA I’ve met has horror stories of the chaos (and probably late nights in the office) that ensued when they were obliged to start work prematurely on poorly-specified tickets.

So to avoid this waste, and to treat our colleagues with some respect, all tickets must be checked with these downstream people (typically Devs and QAs, though perhaps also other roles) in order to be declared R4D. All these groups have to collectively agree, with a real or virtual handshake at the end of a discussion, that a ticket is ‘Ready for Dev’”. Sometimes it might take 60 seconds to get that handshake, sometimes it might take a number of goes and a lot of revision and effort. But it’s less waste in the long-run to have those discussions before coding has started, than to wait till later and all hell has broken loose.

Does this mean every ticket has to go through a massive formal meeting with very single Dev and QA (and possibly others) invited? This is very unlikely to be a good idea, though it is, in fact, what Scrum mandates – Sprint Planning meetings are always whole-team meetings after all, and it’s in those meetings that Scrum tickets are supposedly brought to a ready state. But such uncompromising, universal rules are clumsy and wasteful, and while some tickets might justify the enormous man-hour cost of a big whole-group discussion (where you’ll probably batch up a ton of ticket discussions to try to justify that cost, thus making it a long whole-team meeting), many (most?) tickets certainly do not. Smaller, less formal meetings/chats might be better. Or you might be able to do it in writing – an IM chat, or in a Jira thread. It’s all contextual. Empowered teams decide such matters for themselves.

Exactly who needs to be in such conversations? It’s often enough to have representative(s) of each function that will deliver the ticket. Typically, at a minimum, this is one person from Product (often the one who wrote the ticket), and one each from Dev and QA, a triplet that is known as the ‘Three Amigos’. But perhaps for some tickets there are more than three; maybe UX want to be separately represented, so you have four. The architect has a big say in this ticket? OK, that’s a different mix again. Each team must figure it out for themselves.

So what do we call this step of getting the right people to agree that a ticket is R4D? Since it involves various ‘Amigos’, it might be called ‘Amigoing’. Or since it ends with a handshake, perhaps ‘Handshaking’ is a good name. Either way it is the gateway to R4D, the necessary check that Ticket Prep achieved its goal of putting the correct information into the ticket to allow for effective delivery downstream.

getting tickets ready delivering
Idea Triaging Ticket Prep Hand-shaking R4D bla… Done

So this is where we’ve got to. We know the steps to get tickets from conception to a Ready for Dev state, from where it is safe for the delivery people to pick them up. We’ve made good progress, but have a long way still to go – what happens in Delivery is for another article.

Scrum, Kanban, and the importance of visualisation

On By JPIn Agile Boards, Kanban, ScrumLeave a comment

In a series of articles I discuss the importance of visualisation of work using an Agile Board for effective software development. I contend that while most teams attempt this to some extent, relatively few think about it much or do it particularly well. This article considers a possible reason for this state of affairs: the influence of the underlying methodologies used by such teams.

Scrum is unquestionably the dominant organisational methodology in software development today. Probably second in influence is Kanban, a system whose roots are in hardware manufacturing, and whose principal advocate in the world of software is David Anderson, author of the seminal book on the topic. What is the place of visualisation in each of these methodologies, and how does that relate to what we see in the workplace?

We’ll start with Kanban. The very word itself denotes a visual card, originally used to control inventory in a manufacturing production line:

kanban-board-factory

In Anderson’s porting of Kanban into the realm of software, he states its major principles as follows:

  1. Visualize1 the workflow
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively (using models & the scientific method)

In other words the First Commandment Of Kanban, just as the meaning of the word itself, tell you that visualisation is at the heart of the methodology. Since a ‘workflow’ is precisely the series of steps that any piece of work goes through from conception to finish, you are not even doing Kanban if you haven’t structured your world around an Agile Board (also known, not surprisingly, as a Kanban Board). You would therefore expect practitioners of this philosophy to have thought considerably about how best to create and use such boards, and to be somewhat refined and advanced in their practice of it.

But what about the dominant methodology, Scrum? A search through The Scrum Guide 2016 contains not one mention of the words ‘visualize’, ‘workflow’, or ‘board’, so the contrast with Kanban is immediately clear.

Below are some excerpts from the Guide that could be implemented via something like an Agile Board, but they could be implemented in other ways, even ones that are not visual at all.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog

[In] the Sprint Review… the Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

Monitoring Progress Toward a Goal: At any point in time, the total work remaining to reach a goal can be summed…  This information is made transparent to all stakeholders.

At any point of time in a Sprint….the Development Team tracks [the] total work remaining…[to] manage its progress.

More promising is the language used to describe two Scrum ‘artifacts’, the Product and Sprint Backlogs:

The Product Owner [ensures] that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. [It] is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint

This is more like it! But before we get too excited, remember that a Backlog is really just an ordered list, and lists are hardly rich visual experiences. This isn’t quite a direct command to use something like an Agile Board.

And finally there is this:

Significant aspects of the process must be visible to those responsible for the outcome.

This is the most promising allusion, but no more is said in the Guide – the very next sentence goes on to talk about agreeing terminology and a definition of done, which (while definitely important) are clearly nothing to do with visualisation.

In summary, there’s nothing in the Scrum Guide that stops you using an Agile Board, but there’s also nothing that requires or particularly promotes it, and so you might expect that teams following this programme may try some form of work visualisation, but might not have developed it particularly far – which is exactly the situation commonly found in most software development teams. Thus there is a plausible cause-effect relationship between the low prominence given to visualisation techniques in the dominant methodology, and the somewhat half-hearted attempts at a fully-functioning Agile Board that we see in many real software teams.

No article comparing Kanban and Scrum would be complete without mentioning the best short guide to the two; Henrik Kniberg’s masterful free booklet, Kanban and Scrum – Making the Most of Both is a must-read for anyone interested in the topic, chock full of insights and wisdom, and highly recommended.

[1] a constant nightmare for Brits writing on this subject is having to switch between UK and dominant US spellings of key words

Agile Boards 101 – why visualisation is critical

On By JPIn Agile Boards, Kanban, ScrumLeave a comment

Human beings, like all primates, are primarily visual animals. We depend on our eyes far more than our ears or noses to apprehend and understand the world around us.

primate-human-eyes-1

This means that, to a pretty good first approximation, we are aware of, think about, and respond to (or, in other words, ‘manage’) what we can see, and ignore what we can’t. Since it’s best to work with, not against, the grain of millions of years of evolution if you want to get stuff done, the Prime Directive of effective management is to make your work visual.

By representing your work visually in a unified way across all the group(s) of people involved in that work – those who request it, do it, check it, manage it, pay for it and benefit from it – then all these people will have a verifiably similar understanding of that work: what’s been done, its current status, what’s coming in the near/middle/far future, what milestones have been achieved thus far and what the problems exist. Without such a common understanding of the world and its challenges, these multiple people are not a team in any real sense of the word, and are correspondingly unlikely to make systematic progress together.

It is thus no exaggeration to say that the common understanding of work, that can only be achieved by making work visual, is how you build effective teams, and teams are what allow you to make progress and deliver what the organisation needs. It really is that important. In my experience very few teams have ever given their work visualisation much thought, and as a result not that many do it well, leading to poor coordination and massive waste.

To summarise: in complex fields such as professional software development, if you want to act like a team and manage your work effectively to make any progress, and do not want to risk wasting all your money and time, you must find good ways to make your work visual.

So what kind of visualisation are we talking about? The relevant characteristic of software development is that work passes through a series of discrete steps, moving through many hands as it does so, both between teams, and within teams (the typical sub-teams in software development being: Dev, Test & Product). While this flow of work has some loops and eddies in practice (ie parts of it are iterative), there is still a clear direction of travel, broadly: idea generation and selection – fleshing out – coding – checking – sending live (= done).

Such step-wise work with multiple handovers is best visualised on a two-dimensional grid, where the vertical columns represent the steps that the work flows through, from left to right (or right to left if everyone’s native language is Arabic or Hebrew), and the individual chunks of work are represented by cards or tickets that sit in the columns. Such a board goes under many names, perhaps the most common being Agile Board or Kanban Board. Although the latter is probably the most accurate term, the principle of visualisation is broader than any one methodology, so I will use ‘Agile Board’ by preference.

agile-board-generic

As always, lousy implementation will ruin even the very best of ideas, so such an Agile Board needs to be set up, maintained and used well, and I will write a series of articles on this topic.

In conclusion; proper work visualisation using Agile Boards is the arguably single most important component of efficient management of software development. Only by leveraging our most important sense, vision, can you effectively create common understanding and a sense of teamwork in complex organisations. Most software teams try to implement it to some extent (especially if they are more influenced by Kanban than Scrum), but few think about it deeply and many attempted implementations are deeply flawed, which goes a long way to explaining the wasted money and poor outcomes of much professional software development.

As an industry, we need to do this better.

Stand-ups: the Scrum way is the wrong way

On By JPIn Meetings, Scrum1 Comment

The Daily Stand-up, or Daily Scrum, is a short meeting that almost always takes place in the first half of the morning, usually 10-30 minutes long (the Scrum Guide dictates a quarter-hour).

I like them. They are really important. But any good idea can be messed up by poor implementation, so in this article I will talk about how Scrum says you should do Stand-ups, and some improved variants on that.

First, the name of the meeting. Scrum certainly didn’t invent the idea of a quick daily catch-up meeting, so the term “Daily Scrum” is somewhat presumptuous. The most common alternative name, “Daily Stand-up” has a different problem; it derives from the idea that attendees should be made deliberately uncomfortable by enforcing a standing posture in order to keep the meeting short.

dilbert-standups

Now of course all meetings should be kept as short as reasonably possible while still covering the necessary. But making people stand up is a terrible way to drive this; discomfort is just as likely to make it harder to concentrate or encourage people to arrive late or not at all. In general, the chairing and facilitation skills needed to run good sit-down meetings are more than sufficient for this meeting – adding discomfort doesn’t improve anything. Personally I have no objection to people standing up if they all want to, but it shouldn’t be mandatory and the meeting shouldn’t really be named thus. The optimal name for this meeting is perhaps “Daily Catch-up”, but most companies seem to call it a Stand-up, and to avoid confusion so shall I.

stand-up

Stand-ups almost always happen around the board that represents the team’s work, whether this is in software or physical (usually post-its on a whiteboard). Interestingly, such boards are not mentioned at all in the Scrum Guide, an astonishing fact which I will discuss elsewhere. So although these boards are literally not any formal part of Scrum, they are a critically important element of managing complex teamwork, and it is entirely correct that they are the focus of the Stand-up. Indeed I see the principal function of the Stand-up as being to ensure that The Team Board is correct, and that the whole team agrees it is correct, at least once per day, and tons of other Good Stuff flows from that.

Now there are two basic ways to structure a discussion about finding the optimal fit between a bunch of people (the attending team) and a bunch of work (represented on the board). These are:

  1. people-focussed
  2. work-focussed

The Scrum Stand-up format advocates the first, and this is the wrong choice. What exactly does Scrum tell you to do? You should go round the team, person by person, and each answers the Magic 3 Questions:

Q1: what did I do yesterday?
Q2: what will I do today?
Q3: do I see any impediments?

By the time everyone’s spoken, this format guarantees that you know what everyone is planning to do – there can be no slacking! But it does not of course guarantee that everyone is working on the right stuff; it is entirely possibly in principle and in practice for everyone in a team to have said what they’ll be busy on, but for nobody at all to be working on the Most Important Thing(s). What a waste of a meeting if so. Now a perfect alignment of individual work proposals to team priorities may have come out of the ensuing conversations – I sure hope it did, anyway – but the Scrum format does not focus on that desirable outcome.

The alternative is to make The Team Board the focus of the meeting, and fit people to work in priority order. A well-set up board makes priority order obvious, so you start with the single highest prio piece of work, and ask who’s working on it, to do what exactly, and whether they need any help. A super-short summary of what is agreed gets noted down (when I run these meetings I do this summary real-time within the board software, with everyone watching and double-checking, and it takes an acceptably trivial amount of time to do so).

You then move on to the second-most important bit of work. Then the third. And so on, till everyone has their day’s work identified to the team’s satisfaction. You might keep going a little bit after that to look at what coming up next, or you might end the meeting at that point. Now everyone knows what they’re doing today, everyone is working in priority order, and The Team Board Tells The Complete Truth – Job Done, successful meeting over.

time-out-gesture

This is supposed to be a short meeting, so you have to keep things flowing. When a discussion breaks out in a Stand-up, the team will often let it run for a short time (30 or 60 seconds) to see if it comes to a swift resolution. If not, someone in the team should signal “time out” using the international gesture above (and everyone in the team should be empowered to do this, not just the person running the meeting), and then it’s someone’s job (usually the person running the meeting) to note down who needs to discuss exactly what at a later point in time (often, immediately after the Stand-up). Thus the Action Points / Minutes of a Stand-up are, unlike other meetings, a combination of a) an updated Board and b) a series of discussions whose need has been identified during the Stand-up.

This alternative format avoids forcing people to try to remember what they did yesterday (most people can’t remember what they were doing 10 minutes ago, it doesn’t mean they’re bad colleagues). It asks the sensible question of “do you need any help?”, not some ridiculous question about “impediments”, and most importantly you know for sure and certain that everyone is working on the most important thing they can do. This is guaranteed by the structure of the meeting, and is far, far, far more important to business outcomes than structuring your meeting to ensure nobody is being lazy.

So the golden rules of successful Stand-ups turn out to be:

  • walk the The Team Board in priority order (meaning of course that you have to know how to set up a board)
  • fit people to the work, not vice versa
  • update the board in real time without destroying the flow of the meeting (perfectly possible)
  • keep things flowing with the time-out gesture
  • stop when everyone’s got the day’s work agreed, possibly plus a little look into tomorrow

You can judge the health of a team pretty quickly by the state of their board and their Stand-ups; getting both right is critical. Judging a board is an art in itself, which I will write about separately. But pretty much anyone can observe and judge a meeting; look for the quality of communication and decisions, body language, efficient use of time, what is written down and how, and whether the objectives of the meeting are met quickly and efficiently.

I would encourage anyone interested in a team and/or its deliverables to attend Stand-up(s). Watching people programme or test is often pretty dull (it’s the same as ‘watching people type’), so the Stand-up is the closest you can get to Walking The Line in a factory setting, and your quickest route to assessing the beating heart of a team. Try it – you may well be surprised by what you find, for good or for bad 🙂

 

Story Points are useless for what people think they are for

On By JPIn Estimating, Scrum1 Comment

One of the main functions of Project Management (indeed, Management In General) is to try to get some predictability out of a delivery process. People want to know when stuff will be done, and the question is not an unreasonable one. Indeed in many fields you will get good and reliable answers to such questions – the arrival time of your FedEx parcel, for example. However the field of professional software development has a poor reputation in this regard, and we will consider one aspect of that in this article.

So how do you predict when stuff will be done? Well, one common (and common sense) approach is to break down your big chunk of stuff into multiple smaller chunks of stuff, estimate how long each of those smaller chunks will take, then munge up all the small estimates to answer the original question. Broadly speaking this is the approach taken by many software development teams, the majority of whom run Scrum, the currently dominant management methodology.

So what does The Scrum Bible have to say about this? The 2016 Scrum Guide says your Product Backlog must be estimated (the word gets 9 mentions in the 17 pages of the Guide), and it says who should do the estimating (the Development Team), but it doesn’t say how or in what units. The most common method used is Planning Poker, a topic for another article. The most common unit of estimation is Story Points, and here we will discuss how successful these Story Point estimations actually are.

It can be difficult to explain to people, especially Senior Management, exactly what Story Points are. They are a measure of Effort, not Scheduling, but the classic unit of effort is the man-day. It is quite natural to ask how Story Points relate to man-days, and often the answer is confused and/or confusing, especially when it turns out there are even different types of man-days (real vs ideal – again, a topic for another article).

But let us brush all that aside for now and assume that Senior Management is either on board or does not object, and your team is producing Story Point estimates and using them for forecasting in Classic Scrum Mode. Does it actually work on its own terms? In other words, ‘do Story Point estimates correlate well with how long it takes to get those things done’?

Let’s graph up some actual measurements and see. On one axis of our graphs we will have Story Point estimates (these are typically limited to certain values, like 1,3,5,8,13….). On the other axis we will have calendar time, the time these chunks of work take to get from Start State (typically: going into development) to End State (hopefully: done). This is often known as Cycle Time or Lead Time, nobody can ever agree on the difference between the two terms, so I usually label this axis Time In Progress (as an analogy to Work In Progress, or WIP, a common Kanban term).

Scrum Theory leads you expect that there should be a strong positive relationship between SP and TIP – the higher the estimate, the longer it takes to deliver. On average, work estimated as 8 SPs should take eight times longer than work estimated at 1SP. Is that what we find in practice?

Below I present four such graphs, two from teams in organisations where I have worked, two from the interwebs. Note that the X and Y axes are the same way round in my graphs, and flipped in graphs 3 and 4, but all tell the exact same tale:

estimation-sp-vs-tip-big-data-2016

Source: Agile Fixer

estimation-sp-vs-tip-front-end-2016

Source: Agile Fixer

estimation-sp-vs-tip-andrew-pattison

Source

estimation-sp-vs-tip-michael-dubakov

Source

The conclusion is clear, and for Scrumdamentalists, startling: there is no useful relationship between the two measures. In other words, the SP estimate on a chunk of work is utterly useless for forecasting when it will be done, which in Scrum Theory is the main (only?) reason for doing them in the first place.

I present here evidence from four teams, but have seen this pattern elsewhere over the years, though sadly I do not have the evidence to hand. And whenever I have seen people graph this up with real data, this is exactly what is found.

What do we do with this conclusion? Every activity in delivery should be subject to a cost-benefit analysis. If that activity turns out to have a higher cost than benefit, then it should cease (or at least be reduced as much as possible), and/or done in a different way that manages to produce a net plus to the organisation.

Does this mean that Story Point estimating is a complete waste and should cease immediately? An interesting question indeed. My thoughts:

  1. the villain here is more likely to be ‘estimating in general’ rather than specifically ‘estimating in Story Points a la Scrum’ – but the graphs I have to hand to show SPs as their unit, hence the focus here
  2. if the cost of even inaccurate estimates is low, the urgency of eliminating this activity is similarly low. So if you can do this activity quickly and easily, maybe there’s no reason to change. But bear in mind that there are other potential costs: misleading forecasts can undermine faith in delivery teams and the entire delivery process, which is a serious cost indeed.
  3. if a Story-Point-estimation process has benefits/purposes other than delivery forecasting, it may still pass a cost-benefit analysis.

In fact I have successfully run many teams without estimating at all, whether in Story Points or some other unit – I am far from wedded to this as value-adding activity. And where my teams have done such estimating, we have a) done it quickly, and b) derived other value from it, so it was still a net plus.

And of course abandoning sacred processes is itself hard. The organisation’s need to have a clue when stuff will be done is not going to go away, so if Story Point estimating won’t serve, you probably need to have something else at hand. Once more there’s much material here for other articles, but for now I offer this conclusion:

Story Point estimating a la Scrum can be shown, empirically, to have little or no relationship to actual delivery times. It is therefore useless as a forecasting measure. If that is the only or principal reason for the practice, you should give serious consideration to reducing or eliminating it entirely, as the time spent is wasted and would be better used for other activities.

Terrible Scrum jargon

On By JPIn ScrumLeave a comment

Every field of knowledge has its own jargon, which can be as helpful to insiders (bringing clarity and precision) as it can be irritating to outsiders (bringing obfuscation and exclusion).

Where your field is truly specialist, such jargon may be justified. While a lay person might be confused by a particle physicist’s talk of gluons, anti-particles and wave functions, those words were invented to describe concepts that did not previously exist, and the jargon of quantum mechanics is no more bizarre than the world it tries to describe.

In the more commonplace field of managing software development teams, the underlying concepts are people, their roles, and how they organise themselves and talk to each other, for which vocabulary already exists. When you are trying to improve communications, it’s best to avoid management speak or silly terminology.

The practice of Scrum, the most common Agile methodology, has accumulated a few of these terrible jargon words. The very term ‘Scrum’ itself is an odd one – if you’ve ever talked to a veteran front-rower in a Rugby Union team, they’ll tell you that rugby scrums are a nasty underworld of eye gouging and worse.

rugby-scrum

But perhaps there’s something in the metaphor of ‘8 people all pushing in the same direction’, so we’ll give that one a pass for now. But there are some truly terrible examples of Scrum jargon that we should really do without. Let’s start with the three worst offenders:

1) Grooming (the Backlog)

This word was bad enough before the Jimmy Savile scandal rocked the UK, but these days it’s even harder to keep a straight face. If you have to do something to the Backlog, prepare it, tidy it, organise it, whatever – don’t groom the damn thing.

2) Impediments

This word abounds in Scrum stand-up meetings, in the 3rd question that every team member is supposed to answer. It’s not a common English word, with a stuffy, old-fashioned feel about it, and is mostly associated with speech impediments. The word ‘blocker’ is preferable, but best of all is to ask ‘do you think you’ll have any problems?’ or ‘will you need any help?’.

3) Pigs & chickens

It’s hard to believe this one ever got any traction. It’s based on a joke – which even if well told is still a lousy joke – about the difference between a pig and a chicken’s involvement in the classic English breakfast of bacon and eggs. The chicken is ‘involved’, while the pig is… wait for it… ‘committed’. Hilarious, huh?

This is then used in the Scrum context to distinguish between core team members who must attend vital meetings and participate in decision-making, and peripheral people whose attendance is not mandatory and might not even be tolerated.

While you might sometimes want to make this distinction, I would advise against doing so using words that are not just utterly confusing, irrelevant, and based on an obscure and humourless joke, they are also downright insulting: ‘chicken’ means coward, and ‘pig’ is an insult in a vast array of cultures and religions. A (very nice) English colleague of mine once referred to his Spanish and Portuguese team-mates as ‘pigs’ with this innocent meaning in mind, but they were genuinely outraged and never forgave him.

While these are the worst offenders, two more terms commonly used within Scrum are worth (dis)honourable mention. It has become so familiar to refer to chunks of work in Scrum teams as Stories that it’s hard to remember how bizarre this term sounds when you first encounter it. Although there is a historical reason for this usage (material for a future article), the fact remains that the everyday meaning of the word ‘Story’ has nothing to do with the world of professional software development, and its usage in this context only adds to confusion.

A closely associated term is the infamous estimation unit known as the Story Point. I’m sure many readers will have experienced the struggle of trying to explain what on earth ‘Story Points’ are to a bewildered senior stakeholder, who cannot understand the relevance of this apparent nonsense to his simple question “when will it be done?”. But Story Points are at least an honest attempt to confront very real difficulties with estimation and forecasting, and it’s not as if these problems disappear when you switch unit.

To finish off, it is worth reflecting that Scrum, at its heart, is a system for organising teams around some meetings and a some documents. At least ‘meetings’ and ‘documents’ are uncontroversial terms in a work setting, right? But somehow in much of the Scrum literature these meetings have been elevated to point where they are known as ceremonies, which you may well this is a somewhat pompous description of a bunch of people having a chat around a table in an office. And the documents that are the input/output of such meetings are themselves known as artifacts (this is actually the word used in the Scrum Guide itself), which suggests that some Scrum advocates might have got a little too emotionally involved in the Indiana Jones series of movies.

All in all, while this article is written somewhat tongue-in-cheek, there is a real price to be paid in the workplace for using terminology that is unclear, silly, vain, or otherwise unfit for purpose. If we want clarity of vision and direction for our teams, a good place to start is to use plain speaking, rather than obfuscation and jargon.