


need to look through the project product backlog, identify and estimate a common set of reference user stories. After the workshop, the representatives will bring these reference stories to their teams and will coach them to use the common estimation scale. The key is looking for ways to bring the larger teams together to ensure a common understanding.

Very large teams are typically not collocated, but if they are, it makes the meeting easier to organize. Distributed project teams with overlapping working hours can identify a common time and use a conference call. To vote during the workshop, the teams can use a group chat session in an instant messaging tool.

Distributed teams with no overlapping hours need to negotiate a time that will allow all the representatives to take part in the workshop. Because of the smaller number of participants (relative to using the full team approach), it can help make the workshop easier to schedule.

You can review the pros and cons of this approach in Table-3.



Table-3 – Pros and cons of partial project team estimation workshops

Estimating using Planning Poker

A common technique used for Agile estimation is a version of Planning Poker described by Mike Cohn in Agile Estimating and Planning . In a collocated work environment, each team member discusses a user story. Then, at the same time, all collocated members display a physical playing card that points out how big they think the story is.

The numbers on the playing cards represent abstract story points or ideal days (Cohn 2006). Story points are an abstract, relative unit of measure. The team asks itself, "Is Story B half the effort of story A? Is story C bigger than both A and B combined? Where does Story D fit? Story D is similar effort to story B". A user story worth two story points is about one-fourth the size of one worth eight story points and twice as big as one worth a single story point. Ideal days are the second method for measuring size. Ideal days represent the time something would take without any interruptions. E-mail, meetings, and other corporate overhead aside, a story estimated at 1 ideal day may take around 2 "real" days to complete.

To apply Planning Poker in a distributed environment, the ScrumMaster can read a user story, the team then discusses it and the team types a number into a group chat window. For new teams, calling out, “Ready, set, go!” will help get team members to type their values into the chat window simultaneously. Getting the estimates together prevents the estimate from one team member from influencing other team members.

Teams more comfortable sharing their opinions with one another do not need the “Ready, set, go!” The ScrumMaster can just ask team members directly for their estimates they will respond with their numbers.

When using a group chat window, you need to define clearly where the set of new estimates begins because a long list of numbers in the chat makes it difficult to understand to which story the estimates apply to.

As an alternative, you can use (Cohn Play. Estimate. Plan. You may not be able to enter your user stories if security is an issue for your organization; however, the ScrumMaster can verbally identify the stories and the team can respond by selecting cards. has a built-in timer the team can set after discussing the user story to limit time spent on it.


The product backlog is the backbone for agile software development. For teams to deliver great value to

About the author

AgileConnection is one of the growing communities of the TechWell network.
