Get a grip on complexity – the TTM-matrix

The german version of this post can be found here.
During estimation or planning meetings with my teams I often get aware that the team refers to items that were talked about a few minutes ago. That’s great, since I encourage my teams to put items in relation to each other rather than to a fixed scale like hours or days. But quite often we have to pull up former item again since it already slipped from the minds. E.g. Sprint Planning: The team discusses a backlog item which was filed in JIRA (link) and projected to the wall for discussion. Afterwards we talk about the next one, the next one and so on. At the end of the meeting I ask the team which items they are willing to commit to and then it starts: “Could you show this one again?”, “Did this include the designs?”, “There’s just a smoke test necessary for that one, right?”. This made me think about how to keep things visible and the memory fresh. A few weeks ago then I stumbled across an article by James King who (among other interesting stuff) described the “things-that-matter-matrix”. I tried it with my current team and now I wonder why I never thought of something as simple and effective like this before. Let me explain how it works.

All you need is a table (e.g. on or more pieces of flipchart paper) with the backlog items to be discussed in the first column of each row (I usually use the ticket numbers from Jira). Furthermore you should have some columns with empty headers. When you do this for the first time with a team you should ask them which topics they would like to have in the columns, since it’s a supporting tool for the team rather for yourself. This might be programming languages, other teams, technical layers or anything else that helps the team getting a grip on the complexity of the items. My current team asked for the following columns:

  • Backend
  • CSS
  • JavaScript
  • Test preparation
  • Test execution
  • UX design
  • UX QA
  • Business Intelligence

When we started talking about the items we checked the field in each column if the corresponding area was involved. E.g. if UX designs were needed we checked the field. At the end of the meeting the matrix looked like the one in picture TTM 2. During estimation conversations the matrix helps a lot to work out the complexity of items as well as comparing items to others to get a proper estimation.

When the team is up to committing during Sprint Planning it helps a lot to have this matrix as well. They are able to see which areas are involved, if there was a high workload in certain areas to be expected, if any external support is needed, is there are dependencies preventing a commit and a lot more. But best of all: We don’t have to switch back to former items to remember them, we have all the information available at a glance. Thinking about future enhancements:So far we used the matrix in a quite simple way.

There are a few ideas how to improve it if need may be:

  • Don’t just check the cells but give them a value from 1 to 3 (or any other range) to show the expected amount of work (see picture TTM 3)
  • Use color coding to mark certain facts (e.g. support from other teams needed, dependencies to other items, …)
  • Extend the matrix by a short description

… (to be continued)

I would be glad to get feedback or exchange experiences if someone tries the matrix.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.