Project Estimation: Mapping Size and Complexity

Filed under Agile, Estimation, Kanban | Posted by PMStudent

Complexity in project estimation is important, and yet many if not most project managers seem to ignore it from what I’ve seen.

I have been thinking and reading up quite a bit on relative methods for eliciting estimates for projects.

I’ve enjoyed Planning Poker mostly as a means to get a team working more as a cohesive whole, thinking about the project in it’s entirety and how their own work relates to the big picture.? The process has been able to spark many “ah ha!” moments for my team members when someone who was new to a particular component or area of work became exposed to it.? Sometimes a fresh set of eyes can be very illuminating.

My first steps with teams who are new to these processes are to focus on pseudo-relative (meaning mainly absolute) sizing estimates since that is what they are accustomed to being asked for.? The next step is? talking in relative terms about complexity and size in a way we can calibrate and that makes sense to the teams.

I am going to try something new and see how it goes.

First, Planning Poker

First we? will conduct planning poker, looking at relative complexity of the stories we are estimating.? A story that everyone is familiar with will be selected and discussed as the starting point for our discussions, around which other stories will be judged in relative terms.

If you are new to planning poker, there are many great resources available to learn more about it.

Next, Relative Effort Mapping

Normal planning poker sessions result in a story point estimate you stick with.? What I would like to do here is extend and validate relative mappings with a visual tool used in a collaborative way with the team.

What’s this fancy tool?

A whiteboard and some post-it notes.? Sophisticated, I know…? just like how I do Kanban.

Each of the stories will be indicated on a post-it note.? Use the same colors to avoid any unconscious grouping tendencies.? On the whiteboard draw a 2-axis graph with complexity on the X-axis and size on the Y-axis.? Starting with the calibration story in the center, review each story quickly and have the primary story owner (who will be working/lead on it) place it where they think it belongs on the matrix after having already done the planning poker session.

Pretty simple.? Unnecessary?? Perhaps.

I’d like to experiment with it and see if it yields any new insights or strengthens the understanding of the work to be done within the minds of the team.? My hope is to discover interesting discrepancies between the results of planning poker and the relative size and complexity of the same stories on the matrix.? When experimenting, discrepancies always lead to new insights and questions to be tested further.? If I find no significant or systematic discrepancies over time I will likely abandon the practice, as that would indicate a lack of efficacy.

LIKE & SHARE THIS ARTICLE