Even on only moderately complex projects, it is often difficult to
get a clear vision of the overall project status at any given point
know where to best allocate limited resources
be sure you—as a team member—are working on what you should be
While this is difficult enough with small, collocated teams, things becomes much harder if team members are distributed across time zones. In this article, we’ll discuss how to use a Knowledge / Importance Matrix (K/I Matrix) that is integrated into a collaborative wiki environment to address these issues.
Champion Advertisement
Continue Reading…
What Is a Knowledge / Importance Matrix?
A K/I Matrix is a two-dimensional graph with Knowledge on the X axis and Importance on the Y axis. Each dimension of the graph ranges from 0% to 100%. Figure 1 shows an example of a K/I Matrix. We define the dimensions of this graph as follows:
Knowledge—How well a team understands a task.
Importance—The relative importance of a task to project success.
Figure 1—Example of a K/I Matrix
In a particular project’s K/I Matrix, all outstanding tasks fall somewhere on this graph, and the result is a clear overall representation of task status. In graphing these tasks, there are three major regions of interest, as follows:
research—Tasks on the left half of the matrix require research to better understand them—that is, to move them further along the knowledge axis. The most attention should go to tasks with the highest importance ratings, but as knowledge of tasks increases, the team may decide to revise their importance ratings.
build—The upper-right quadrant holds tasks that should receive priority for implementation. These tasks are important and well understood and need to get implemented.
question—The team should question tasks that end up in the lower-left quadrant. They may not be worth completing. Even if the team eventually drops these tasks, it is valuable to track them to show that the team considered them and judged them to be nonessential.
Projects, Features, and Tasks
A K/I Matrix comprises the following:
a project—Each K/I Matrix is associated with a single project. A project is a long-lived initiative. It could be either a new offering, a major enhancement in functionality to an existing offering, or a minor enhancement.
features—A feature is a single, complete set of functionality; is part of a project; and comprises multiple, specific tasks.
tasks—A task is some specific piece of work that is part of creating a larger feature and, usually, only one person owns a task at any given time.
For example, an ecommerce Web site project might have a shopping cart feature. For that feature, one task might be creating a shipping calculator. Individual team members focus primarily on tasks, which roll up into the creation of a feature for a product.
In the example K/I Matrix for a project, shown in Figure 2, there is a full feature list to the right of the matrix. Tasks that are currently in progress exist in both the matrix and the feature list. Completed tasks appear only in the feature list.
Figure 2—Project K/I Matrix with a feature list
Creating and Maintaining a K/I Matrix
A K/I Matrix is a living, evolving project resource. At the outset of a project, a K/I Matrix is a useful tool for brainstorming features for a project, the tasks that implementing those features would require, and the relationships between all of these.
At regular intervals, a team should revisit the K/I Matrix for their project and make adjustments. Over time, as the team’s knowledge grows, tasks should move toward the right. As a project evolves, a team can add new tasks, if necessary; remove any tasks that the team deems to be out of scope from both the matrix and the feature list; and remove completed tasks from the matrix.
Integrating a K/I Matrix with a Wiki to Support Collaboration
The K/I Matrix is useful for communicating a project’s big-picture status, but it lacks the necessary detail to support day-to-day task coordination. In order to accommodate that need, a K/I Matrix should reside on a wiki that acts as a portal to more detailed project information. Each task item in the matrix should link to a wiki page, showing details that include the following:
task name
task description
associated features
current task owner
dependencies
and any other relevant information
There should also be equivalent feature and project pages, holding information relating to the features and the overall project. Since a wiki comprises simple Web pages, it’s a simple matter to cross-link project, feature, and task pages to external resources such as a content management system (CMS) or defect-tracking tool. Together, the pages on the wiki provide complete information about a project.
The wiki allows distributed teams to collaborate in moving a project forward. This evolving, single point of contact ensures that the members of a team stay in sync, because there are no stale documents to get out of date. The K/I Matrix and wiki change continuously to reflect the current state of the project.
Taken in total, the project wiki serves as the design, test, documentation, and implementation specification. Each builds on the other, and any team member can make revisions as necessary.
K/I Matrix in an Agile Scrum Process
When applied to an agile scrum process, the K/I Matrix both organizes and visualizes the state of user stories before they are ready for assignment to a sprint for implementation.
The typical user-story list is one dimensional. Teams can sort only by overall importance. But does that equate to how important each story is to the overall project or how close the story is to being ready? Most often, it’s probably a combination of the two. In a flat list like that, how can one pick out, at a glance, the high-importance stories that are poorly understood and need work for them to be ready for a sprint? There is no simple solution, because a simple, one-dimensional, flat list is too limiting—it doesn’t show enough information.
The two dimensions of a K/I Matrix give a product owner and the scrum team much greater insight into the state of the user-story backlog. Stories of high importance that are not well understood and need refining become obvious. They congregate in the upper-left quadrant of the matrix. These are the stories that need the most attention during backlog grooming and research tasks.
A K/I Matrix provides an alternative view of a scrum team’s user stories. A K/I Matrix that is linked into a Web-based tracking system can act as a portal into user story and task details. In this way, it can augment existing tracking tools an agile development team uses.
Conclusion
A Knowledge / Information Matrix provides a two-dimensional, visual approach to prioritizing tasks, assigning resources, and assessing progress on a project. It lets people quickly see the big picture in a way that a simple list cannot. It also acts as a gateway through which a team can obtain more details about individual items. Because a K/I Matrix is a living resource that a team works with on a regular basis, it can foster collaboration and help build consensus within a group.
In summary, a K/I Matrix is a relatively simple tool that you can add to any development process’s set of tracking tools to gain new insights and recognize opportunities you might otherwise overlook.
Principal User Experience Architect at AgileAssets, Inc.
Austin, Texas, USA
A software designer since the mid-90s, Mike has worked with teams who were responsible for creating a wide range of Web and rich-client applications serving many varied industries. Before joining Continuum Managed Services, he was a key contributor to design efforts at Autodesk, Oracle, Unica (IBM), Chordiant (PegaSystems), and Bowstreet (IBM). Mike studied electrical engineering and computer science prior to cultivating a career in software design. He is an active member of IxDA, ACM, and the local New Hampshire and Boston chapters of UPA. When not busy improving product user experiences, Mike is an avid performing musician and songwriter. Read More
Karen has nearly 30 years of experience in technical writing, information architecture, instructional design, curriculum development, and training delivery. At Autodesk, Karen designs and develops user assistance, including wiki Help, video tutorials, and self-paced learning courses for building design engineers. She has also developed e-learning courses and taught online classes for a variety of software platforms and users. Karen is a member of the Society for Technical Communication. Read More
