{"id":296,"date":"2015-08-01T09:10:31","date_gmt":"2015-08-01T09:10:31","guid":{"rendered":"http:\/\/www.scrummable.com\/?p=296"},"modified":"2017-06-06T13:05:18","modified_gmt":"2017-06-06T12:05:18","slug":"silent-grouping-better-than-kevin-spacey","status":"publish","type":"post","link":"http:\/\/scrummable.com\/silent-grouping-better-than-kevin-spacey\/","title":{"rendered":"Silent Grouping: Better than Kevin Spacey"},"content":{"rendered":"

Everyone understands the importance of being able to predict the future. And as software teams, we\u2019re asked to do this a lot<\/b>.<\/i> Like it or not, there\u2019s any number of stakeholders working with, or affected by, your project, and one of the things they\u2019re going to be particularly concerned about is the delivery date. It\u2019s an inevitable part of the software development process. Sometimes, they\u2019re the people paying for it. Sometimes, they\u2019re the people marketing it. Sometimes, whether you get paid or not depends on it.<\/div>\n

\"A<\/a>

A sterling example of the benefits of predicting the future.<\/p><\/div><\/p>\n

Unfortunately, in this world of agile and scrum and kanban and waterfall and kanbanterfall and all of the other wonderful software project methodologies, you\u2019re going to run into the tension between the certainty of a delivery date, and the certainty that you don\u2019t know enough to make that call. And, not getting into the whole \u2018estimation is a myth\u2019 debate (that\u2019s for another article), for the sake of argument today I\u2019m going to acknowledge that there are a number of ways to predict the future, and that some of them may be more accurate than others.<\/p>\n

Story pointing is a pretty long-held method of predicting the perceived effort involved in the delivery of a feature, and is often the tool used to extrapolate those estimates into a delivery date, on the basis of historical trends in your team. The idea is that we start with the smallest estimate for the smallest feature we can think of, and then everything else is estimated in relation to this: so, changing the colour of a button may be a \u20182\u2019 (2 means nothing), whereas changing the size and position of that button may be anywhere from a \u20183\u2019 to a \u2018100\u2019 (again, the number means nothing) depending on complexity. If we don\u2019t have enough information to assign a perceived \u2018effort\u2019 against a ticket, or if the estimation we have arrived at is too big, we go back to the drawing board, breaking the feature down further where we can, and gathering enough information in order to be able to decide on how much effort we think the ticket might take.<\/p>\n

The idea is that the numbers you assign inherit meaning as your workflow becomes established within the team: after a prolonged period of time, you team can get so accurate at this (and so familiar with their own process and ways of working) that \u20182\u2019 can subsequently translate to 3 days from development to completion of a feature for example. There\u2019s a lot of negatives to this, and lots of teams make the mistake (and it is very<\/i><\/b> easy <\/b>to do so) of directly equating points to time way<\/em>\u00a0to early in the process – but if you can do it right, it can become a reliable method for working out how long things might take to build.<\/p>\n

Arguably the most prevalent method for doing this is planning poker. Planning poker involves a deck of cards, each marked up with a \u2018points\u2019 estimate on a scale (estimation traditionally runs off the Fibonacci scale, so the order goes 1,2,3,5,8,13,20(sometimes),30,100 and so on). Each member of the team (and this exercise should involve everyone from the project, so all disciplines) gets a set of cards containing each number.<\/p>\n

\"The<\/a>

The Fibonacci Scale. The loveable snail of software development.<\/p><\/div><\/p>\n

The tickets for estimation are taken in turn, and the feature or problem we\u2019re trying to solve is presented to the team. Once the feature has been explained, and any kinks or edge cases deemed important are nailed down in terms of approach, everybody plays the card they think reflects the effort it would take to complete the feature. If the numbers played don\u2019t match, further discussion happens, and further hands are played until an agreement on estimated effort is reached. Points as mentioned are arbitrary, but any points assignation should be done based on previous experience. If you have none, it\u2019s guess-work; and it should be widely known by all stakeholders that even if we\u2019re guessing to begin with, this isn\u2019t wasted effort – it\u2019s a vital part of establishing a benchmark against which you\u2019ll work in the future.<\/p>\n

This exercise is incredibly useful, in that it allows people of all levels of experience to outline what they think the challenges inherent to a ticket will be – and it means that an estimate isn\u2019t arrived at based on one team members\u2019 experience, because we want to remove as many dependencies from the process as possible; what if the team member who estimated the ticket isn\u2019t available to do the work, and someone else has to pick it up for example?<\/p>\n

However, planning poker requires discipline; often these meetings can last several hours and can quite easily diverge into technical implementation discussions, wider product ambition discussions and so on, and the longer they last the less likely your estimates are to accurately reflect the work as attention wains. Estimation sessions, if not tightly controlled, can often become seen as a bit of a chore and a waste of time – and the more people involved (which by rights there should be to ensure a balanced set of views are represented), the more expensive they become.<\/p>\n

So, how can we make this process just as accurate, but shorter and less time-consuming for everyone involved? Another approach to try (that in my experience works particularly well) is called \u2018Silent Grouping.\u2019<\/p>\n

Silent grouping (i\u2019m not going to lie) looks a bit weird. The basic idea is that all of the tickets you want to estimate are stuck to a great big whiteboard in an unprioritised column. Next to this are a further series of columns, split by your estimation flavour of choice – this could be time, points, t-shirt sizing, kittens, whatever you use. Each ticket should have the story detail associated with it to enough of a level that everybody should be able to understand the task at hand.<\/p>\n

\"These<\/a>

These kittens mean nothing. They are a metaphorical representation of perceived effort. Deep.<\/p><\/div><\/p>\n

At the beginning of the session, the tickets are outlined by the BA\/PM and any obvious questions or edge cases\/considerations are nailed down to ensure everybody understands the work required for each of the tickets. Once this briefing is complete, the entire team lines up in front of the board. From this point forward it is absolutely essential<\/b> that no-one speaks. No discussion should be had between now and when the exercise is completed.<\/p>\n

One by one, each team member picks up a ticket (in any order from the batch of tickets) and places it in the column that they think most accurately represents the work involved in the task. The person taking their turn can also elect to move a ticket that has already been assigned an estimate if they feel the estimate already given doesn\u2019t reflect the work involved. This process is continued in multiple cycles until all tickets are assigned to a column on the board, and tickets are no longer being swapped from column to column.<\/p>\n

\"Although<\/a>

Although dancing, all of the people in this image are silent. Silently grouping. Always grouping.<\/p><\/div><\/p>\n

The beauty with the process of silent grouping is that removing the discussion element from the process has a threefold impact:<\/p>\n

    \n
  1. It\u2019s fairer. <\/b>Teams are made up of a wide range of personalities, and it can become easy during a traditional planning poker session for the loudest personality to dominate the discussions. Silent grouping removes this element, allowing each person to silently contribute their opinion, affording equal weight to everyone.<\/li>\n
  2. It improves accuracy. <\/b>Removing the discussion element allows people to focus on the tasks for estimation personally. Any feature we build involves a multitude of complex processes, and during a traditional estimation session it would be impossible to cover all of these in detail as a group – there\u2019s just too much to consider. Silent grouping allows each member of the team to consider each ticket individually and from their own perspective, and as such it usually results in a more well-rounded consideration of both the task at hand and any potential pitfalls that may arise<\/li>\n
  3. It can save time. <\/b>Surprisingly enough, and probably as a direct consequence of point (2), silent grouping disagreements over the weight of a ticket often sort themselves out in a couple of cycles. The fact that each person can consider tickets individually and without input from other team members means that each person can come to their own conclusions about the reason behind a disagreement, and challenge themselves to determine why someone else may consider a ticket bigger or smaller than they would. This can neutralise any lengthy debate process that can often arise in a traditional planning poker session, making the process much quicker.<\/li>\n<\/ol>\n

    Although the process sounds like it may be a lengthy one, it\u2019s been consistently suggested that once silent grouping is embedded as a process within a team, it can reduce the time taken to estimate stories significantly to a fraction of what it takes to complete a traditional planning poker session, whilst simultaneously improving accuracy. The fact that the process is accelerated also means that an estimation session can become something the team actively looks forward to, rather than becoming a source of dread.<\/p>\n

    So, silent grouping – remember, if you\u2019re going to have to predict the future, it\u2019s best to do it quietly<\/i>.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Everyone understands the importance of being able to predict the future. And as software teams, we\u2019re asked to do this a lot. Like it or not, there\u2019s any number of stakeholders working with, or affected by, your project, and one of the things they\u2019re going to be particularly concerned about is the delivery date. It\u2019s […]<\/p>\n","protected":false},"author":4,"featured_media":595,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,6,10,3],"tags":[],"_links":{"self":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/296"}],"collection":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/comments?post=296"}],"version-history":[{"count":0,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/296\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media\/595"}],"wp:attachment":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media?parent=296"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/categories?post=296"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/tags?post=296"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}