Working with organizations transitioning to agile I often find that estimating is one of the first areas of discomfort, and story point estimating is just too hard to grok for most. After all, most developers have been giving estimates based on time for most of their careers, and we come along and ask them to think of relative points for estimating. It often goes over like a lead balloon.

Relative T-Shirt sizing

To ease the transition I use physical aids. T-shirts to be exact. Raiding my closet for shirts of various sizes, I bring them out on estimating day and lay them on the table in front of us. Remember, this initial story sizing happens to gauge the general size of the effort to help product owners with sprint planning.

Sizes range from Small, Medium, Large, XL, and XXL. For the small, I ask the team to consider the smallest amount of work that could be accomplished in one Sprint. Don’t fret over breaking down the story into parts, that comes later in Sprint planning. Just consider the work required to complete this one piece of functionality and that gets an estimate of small.

Next consider work that is larger than small, but not quite considered large. Then medium to large, etc. It’s a relative comparison between each sizing.

Medium to Large relative sizing

With the other sizes in plain view, the team can make mental comparisons between the work required from a small to an XXL. Each sizing from small to XL represent stories that can be completed in one sprint. The stories for XXL, well, they’re just too large to effectively estimate. I tell them to consider these the major pieces that need attention by the BA or product owner to break down.

As the team gets used to the relative sizing, I’ll ask them what they are considering for the small – is this like a one day effort? What does the medium feel like – less than a week? This is a transition activity, and I’ve found that a nice give-and-take discussion around the sizing helps us move along.

With a little visual aid the teams quickly move on to estimating the work using the relative sizing concept. Not to mention they have a lot of fun calling out ‘medium’ or ‘large’ rather than abstract story point numbers.

Now, if you’re a project manager or scrum master that needs to project a schedule of relative effort in terms of time, and management does not want to wait for a couple of sprints to pass so you can measure velocity, you have the option of producing a rough (I emphasize rough), straw-man schedule based on these t-shirt sizes.

Relative to time estimates

For this I’ll take the feedback from the team on the relative sizing. If they said small was less than a day’s effort, and medium was less than a week’s effort, then that’s what I’ll use in translating the relative estimates to a project duration projection.

In this case you’ll see the XXL t-shirt is not translated into any size since this was un-estimatable in its current form. The teams I’ve worked with had a much better time estimating from sizes with the rough translation into time than just straight story point estimates or time estimates on the stories.

As I left a client site and took my shirts with me, I observed the existing project manager gather up t-shirts to continue to use with the teams for estimating. Here’s wishing your good ideas carry on as well!

1. Daily stand up meetings. Those short meetings where every team member stands in a circle and reports on what they’re working on and what roadblocks they are encountering. Getting everyone together once a day to share what they’re working on and what roadblocks are in their way is a great way to begin to build an Agile team.
2. Agile board. Posting the story cards in a visible location and enforcing the status indicators (yellow, green or red adhesive dots) is a powerful tool in raising the team’s awareness of the weekly schedule and progress.
3. Team Planning Sessions. Planning as a team is a powerful productivity tool. As the developers, business analysts, and product managers gather together and discuss the goals for the iteration and the ensuing tasks, the team takes ownership of the project plan instead of the lone project manager. With the team’s commitment to the plan, the project manager now can work for the team by removing roadblocks and providing support as needed.

That’s right, the key items are focused around forming teams. In an Agile environment it is the team that builds success. The best way to begin to see the impact of Agile is to start forming, empowering, and supporting teams.

What convinces me about these 3 simple steps is that I’ve seem these work in non-Agile organizations – and have seen first-hand the benefits of teamwork. We’ve known this for years in project management, with organizations focusing on team building exercises and excursions, team guidelines, and the like. It is that Agile takes these principles and provides a framework in which to consistently apply them. Simple concepts like team members sitting together, all the time, not just during critical project junctures; team planning, all the time; daily team communication, all the time.

It’s one of the things I like best about working with clients, helping to set up the structures for teams and seeing the teams form and grow. Kind of like gardening, where with the right materials and environment wonderful things can grow! Maybe that’s why I also like gardening so much

Mentoring, organizing user groups such as Agile Groupies, volunteering with the Women’s Exchange of Washtenaw, are all ways HSG Consulting works to give back to the community.