Using Silent Grouping to Size User Stories


User stories are used to describe the functionality delivered in a product or system. Planning Poker is a common technique for sizing user stories, but it can sometimes be challenging. It can be time consuming and teams can get bogged down in unnecessary discussion. There is a technique called Silent Grouping that can be used to compliment Planning Poker, allowing large sets of user stories to be sized in minutes. Silent Grouping has several advantages. It is fast, which in turn leads to significant time and cost savings.

The Silent Grouping Technique


Silent Grouping is a facilitation technique for getting people to group related items without talking. Jean Tabaka has a summary of the technique in her book ‘Collaboration Explained’ as part of a set of techniques used to help teams process large amounts of information. Jean’s variation of the technique is described in the context of conducting a retrospective, but it is equally applicable to grouping user stories.


There are variations in how this technique is applied. I usually apply the technique in four parts: preparation, individual placement, group placement, and, finally, discussion and reflection. Each part serves a specific purpose, as shown in the table:




Lay the ground rules; set expectations

Round 1: Individual Placement

Quickly get an initial size estimate for all of the user stories

Round 2: Group Placement

Give everyone an opportunity to (silently) provide input to all user stories

Discussion and Reflection

Resolve any disputes; reflect on experience; gain consensus before moving on; discuss insights


The facilitator prepares the board. The columns represent the groups referred to in the name of the technique. The team needs to decide on a scale to use for user story point sizes. Many agile teams now use the Fibonacci sequence for user story point sizes. The user stories should be placed somewhere visible and easily accessible so a smooth flow can be established. Pinning or sticking them to an adjacent wall space or laying them out on a table works well. The board should look like this before the team begins:

Blank Sizing Wall for Silent Grouping

It is a good idea to prepare a Parking Lot for any user stories whose grouping cannot be agreed. I usually put this just beside the Grouping board.

Choose and agree a mid-size user story for starting off. This is the bench mark against which the first few user stories will be compared. After that, triangulation will take over and people will size the current user story against all currently sized user stories.

If the team is new to Silent Grouping, the facilitator explains the technique as part of the preparation, and answers any questions.

Round 1: Individual Placement

Team members take turns, one at a time, to place one user story on the board. The goal in this round is to get all the user stories on the board, and hence get an initial size estimate for all user stories.

I find that simply forming a line is the easiest way to run this part of the exercise. As each person takes their turn, they rejoin the back of the line.

Round 2: Group Placement

The team stands around the board. At this point all user stories are on the board. Team members take turns stepping forward and moving one user story at a time. The goal in this round is to get to team consensus on the size of all the user stories.

There can be contention in this round. A user story can get moved repeatedly, e.g., one team member can move a user story, e.g., from a 5 to an 8, and another team member can move it back to a 5. The team has been instructed to consider why the user story might have been moved. Very often, this act of observation and conscious consideration is enough to resolve the disagreement, and the parties will agree on a size without any verbal discussion.

It can happen that two or more people will move a user story back and forth between two (or more) columns, and nobody is prepared to compromise. This is generally a signal that more discussion is required for this specific user story. As the facilitator, when you observe this interaction just remove the user story form the board and place it in the Parking Lot that you prepared earlier. In practice I have found that this tends to occur relatively rarely.

Risks to watch out for in this round include people not participating. This can take a number of forms. They can stand back and just observe, and not size anything after Round 1. They can become disengaged and not observe the proceedings at all. Both of these can be signs of underlying issues. This is where the skill and experience of the facilitator is important, first in recognizing the symptoms, and then dealing with it.

Discussion and Reflection

The facilitator facilitates a short discussion between the team to gauge the level of confidence in the sizes. The Fist of Five is a good technique to use here. It quickly gives a sense for how confident the team is in the sizing that they just performed.

Full Sizing Wall for Silent Grouping of User Stories


I used to use a ‘?’ column to group user stories that people felt could not be sized because there were too many unknowns. Planning Poker has a ‘?’ card too. However, I found that this provided too easy a way out. I want to provide a situation where teams are forced to either make a decision or openly disagree with each other and question the size of the user story. Decide what’s appropriate for you, but these days I prefer to not use the ‘?’ column.

Summary of Benefits

I have observed the following benefits from using the Silent Grouping technique:

  • It is very fast. You can size large sets of user stories in minutes.
  • It is scalable. I have used this technique with up to 8 Scrum Teams (55 people) in parallel, to size 677 user stories in 28 minutes.
  • It very quickly surfaces any unknowns or areas of disagreement within the team.
  • It is inclusive. Everyone gets the opportunity to comment on all user stories.
  • It works well as a compliment to Planning Poker. You can size initial benchmark user stories using Planning Poker. For any user stories that don’t gain consensus during Silent Grouping, you can size those with Planning Poker.
  • Because the Silent Grouping technique explicitly disallows talking, it is easier for more introverted team members to exert their influence. Conversely, it is harder for more dominant team members to exert their influence just by force of argument or discussion – something that can happen in Planning Poker.
  • If there are language barriers in your team, e.g., if you work with global teams who do not share a common first language ( a very common scenario these days), then Silent Grouping is a good leveler.
  • You can sometimes observe a noticeable delay among Planning Poker players as they wait for others to show their hand first. With Silent Grouping, particularly in Round 1, people must make a decision themselves without influence from others.
  • Silent Grouping applies the wisdom of the entire team to quickly size large sets of user stories. Just like in James Surowiecki’s book, the team will be familiar with the problem domain already. E.g., in one of the early examples in Surowiecki’s book, the people guessing the weight of the cow were all experienced farmers. If it is a truly new problem domain for the team then they need to spend some time before sizing just getting familiar with the problem domain.

Playing Silent Grouping at the XP2011 Conference

I had prepared some slides for my session at the XP2011 Conference, but as it turned out, I did not use the slides. Instead, I decided to run an actual Silent Grouping session. I asked for seven volunteers to pretend to be a Scrum team, and one other volunteer to be a time keeper.

XP 2011 Participants Playing Silent Grouping

When teaching this technique it’s useful to have a backlog of user stories already prepared. Rather than try to come up with a contrived product example, I like to use animals. Most people are familiar with most types of animals, so it makes for a good problem domain. To simulate reality, add in a couple of unfamiliar animals, or some that might appear to be ambiguous. For the XP Conference I used 42 sticky notes with stickers of animals. Some animals were represented more than once.

The team sized all 42 user stories in about six minutes.

Animal User Stories After Silent Grouping

Several people who came to my session at the XP Conference tried it out when they got back to work, including @ruby_gem.

Slide Deck

The slide deck is here:

Research Paper

My talk at XP2011 was based on a research paper that I submitted to the conference, and was published as part of the conference proceedings. I was delighted to be named in the final four at the conference banquet for the award for Best Research Paper.

The paper draws on experiences of seven Scrum teams as examples. The paper shows how to apply the technique with co-located teams, and includes an example of how it was used with distributed teams. The paper is 15 pages long and contains some data, charts and more detail on the technique and its application. The proceedings are available from Springer.

Let me know how you get on

I keep records every time I run this, and I also keep records of other ScrumMasters and coaches that use it. I would love to hear how Silent Grouping works out for you. Get in touch and let me know the following. I’ll be happy to credit you in any future papers.

  • Team size
  • Number of user stories
  • Time to size the user stories
  • Number of user stories that needed discussion afterwards
  • Number of user stories sized with Planning Poker
  • Any comments, experiences or insights from you or your team

37 thoughts on “Using Silent Grouping to Size User Stories

  1. […] チームアクティビティ: チームによっては見積もりに苦労することがあります。ストーリーポイントは見積もりに妥当なフレームワークを提供します。チームで妥当な見積もりを引き出すアクティビティに取組みましょう。このエクササイズを始めるには、ホワイトボードにストーリーポイントの値 (0.5、1、2、3、5、8、13、20、40、100) を横に並べます。次に、チームメンバーに最も妥当だと思われる値の下にユーザーストーリーを配置してもらいます。多くのストーリーは 1 つの数値に集まります。ストーリーポイントの値に関して異論がある場合は、その理由を議題に話し合いを始めてください。 […]

  2. […] Молчаливая группировка. Не так давно я писал о том, как можно в течение короткого времени оценить большое количесво Историй и как создавать эстимационные сетки. Прекрасной надстройкой к этому упражнению может служить молчаливая группировка историй, во время которой команда не обсуждает вслух размер той или иной задачи, а каждый имеет право молча передвинуть Историю в нужную по его мнению секцию. Подробно об этой технике вы можете прочитать здесь. […]

  3. Estimation and Story Points…

    Story Points A Story Point is an abstract unit of effort used to indicate relative sizing of development tasks. It is abstract to show that it is relative and not strictly related to actual time. It is recommended, however,……

  4. Good post. We’ve used the White Elephant Game, as mentioned before, a few times and it’s always worked really well. The only change we make to it (and that I suggest you make to the above if it’s relevant) was to pick a story from the teams current backlog as a mid-sized story, something they’ve actually completed. This is a much better way of getting a benchmark.

    The reason we changed it is that, if the mid-sized story you pick first is not a mid-sized story, then you run the risk of over or under-estimating the whole rest of the backlog.

    We estimated a project this way and the total of the estimates for the team that estimated it set the project at 21 weeks (based on their velocity), when the team itself had said it would only take 15 weeks after a long discussion with the PO prior. When asked whether it would take 21 weeks, they said no, it’ll only take 15 still and when asked about the discrepancy, they said they felt that all the stories, while relatively estimated, were estimated higher than if compared to their current product backlog and the problem stemmed from an incorrectly placed mid-sized benchmark which no-one noticed.

    There are a few factors which will cause the above mentioned issue and you may not experience, but by picking an existing story from the current backlog, you mitigate the risk entirely.

  5. Hi Ken

    I like silent grouping. I’ve been using that as part of a series of release planing refinements that I call the Planning Poker Party. I tell attendees of my session at Agile 2011 to stop doing using planing poker, it’s too slow. Actually I recant that. I like to group and then label the relative size of each grouping using planning poker. Read more here:

    Well done, James

    • Hi James,

      Thank you for your kind words. You have had such an amazing impact on the community with Planning Poker. I still have my first deck of Mountain Goat Planning Poker cards (thanks Anthony). I love your slide deck – great content – and the Planning Poker Party looks like a lot of fun. I agree we need to spread awareness of alternative approaches to sizing and estimating, and when its appropriate or useful to use them. All the better that we can have fun at the same time!


      • Thanks for your kind words. I’m amazed at how a small simple idea that helped unblock a meeting has led to the world-wide use of Planning Poker.


  6. Hi Ken,
    Haven’t come across this technique before but it certainly holds promise (talk is overrated!). One question – 677 stories across 55 people in 28 mins – how could everyone have a chance to consider each story? Is there an optimum no of people/stories for such an estimation session?

    Thanks, Colm

    • Hi Colm,

      The 55 people in the example are from 8 Scrum teams, all working on the same product. I split them into 8 groups for this exercise – each group is a Scrum team. Each Scrum team sizes just their own user stories. It’s not a case that all 55 people need to consider all 677 user stories; each Scrum team just considers their own. The exception in this example is that there were people who had experience across multiple Scrum teams, so I added a third round for getting cross-team input. This is included in the 28 minutes.

      About the optimum ratio of people to stories, I haven’t come across a limit yet. I’ve never tried to limit it when doing this exercise. I’ve always gone with the approach that we size the full backlog that the team is being asked to plan for. That’s ranged from maybe 10 user stories per Scrum team at one extreme, to maybe several dozen or a couple of hundred. The XP2011 paper has some case studies, and I’ve been compiling more since. In all the scenarios I’ve used this in, the ratio has never proven to be an issue.

      Yes, these kinds of technique are great for bypassing unnecessary discussion, and it also quickly highlights where discussion is really needed.


  7. Great post Ken!
    I do something very similar. I can’t see myself ever going back to Planning Poker. 🙂
    I call it ‘White Elephant Sizing’:

    Another good technique is to space your sizing columns relative to each other. For instance, if you’re using Fibonacci, then 1, 2, 3 would be close together, 5 a little further, 20 at the end of the wall, and 100 would be out of the room. I like to do this because I’ve noticed people bumping stories up and down a column if they were at all different in size to existing stories without paying attention to the values.

  8. […] I had a chance last week to apply “Silent Grouping” with a client, and since I found it to be a very positive experience I would like to share it with you here. Ken Power led a session on “Using Silent Grouping to Size User Stories”, and even though I missed that session I did get to read about it in the conference proceedings.  You can also read his detailed post on the technique at his blog System Agility. […]

  9. Ken,

    I’m a fan of the Team Estimation Game, which is quite similar to your approach. I like the “silent” part, because I very often need to remind the teams not to go into detailed technical discussions. There’s also “Magic Estimation” which starts from a different perspective but contains a silent round as well. Looking forward to sharing my experiences in estimating with you at ALE 2011.


    • Thanks Sven. Yes, there’s a lot of power in silent approaches. It’s amazing how accurate they prove to be. Team Estimation Game and Magic Estimation look great too. Looking forward to discussing with you more in Berlin.


  10. Thanks for sharing this, Ken.
    Awesome again. I was sad that I had missed your session when Eelco told me about it, but now I could recount what happened and read about what you did… Impressive.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s