“The purpose of a scrum is to restart play with a contest for possession after a minor infringement or stoppage.” – World Rugby, Law 19

In 2010, I worked as a taxonomist (and content and records management specialist) on a project in which I was embedded in a software development team dedicated to using the Agile methodology. At the time, I wasn’t familiar with Agile. I wasn’t a software developer and had never had the opportunity to work in an Agile shop. I learned a lot about Agile on that project and saw the advantages of developing taxonomies in tandem with software development using the Agile methodology. I presented on this topic at the 2011 Taxonomy Boot Camp Conference as “Agile for Managing Taxonomy Projects”.

Years later, Agile is still a widely practiced software development methodology and, at least in my work experience, taxonomists are still embedded in technology teams and work with both the business and developers in iterative sprints. Since Agile is really a set of practices which can be adopted in part or in whole, let me focus on a few aspects and how they work well with taxonomy development.

The Scrum

The origin of the term scrum comes from rugby, with the idea being that a single, cross-functional team is working together to accomplish a goal. If you watch ruby, you might see it, as this American does, as a chaotic scramble of pushing and shoving out of which a strangely shaped ball eventually is released, hopefully carried by a player. Both the idealized goal of the team and the actuality of the scrum sound a lot like a typical workplace, so I believe the idea fits. Scrum “prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. A person in charge of a scrum team is typically called a scrum master” (Wikipedia).

There are several scrum concepts which fit neatly for both software and taxonomy development:

• Determining the scope of work,
• Understanding the amount of time in which that work must be completed, and
• Working iteratively to accomplish the work and deliver a finished product.

The working taxonomist will note that taxonomy development is not nearly so neatly defined as to follow prescribed, time-boxed sprints. Especially true is that it is difficult to deliver independent, discrete taxonomy hierarchies (or full taxonomy schemes) due to the interconnected nature of multiple taxonomies bound by a single ontology. However, while restricting a portion of taxonomy development to a single sprint may be impractical, the overall guidelines of the functionality to be delivered in each sprint may be aligned with the supporting taxonomies and iterative development can still be accomplished and delivered in step with technical functionality.

In my experience, one of the most valuable features of the Scrum methodology is the daily scrums (or daily stand-ups). In these meetings, understanding what technical development is happening, and especially what changes may be occurring to deliver the right functionality within the sprint, is critical for taxonomy delivery. Separating taxonomy development from software development is one thing, but taxonomy delivery can’t be separated from functionality. If components of the taxonomy and/or ontology are essential for delivery, then it must be clear which components and how it is to be done within the software delivery. Will only taxonomy labels be delivered? What about alternative labels, definitions, or other properties? Will relationships be part of the ontology delivery and how will this be done? Does the functionality support hierarchy and, if so, is there a restriction around how many hierarchical levels? All of these are technical requirements, and, as often the case in Agile software development, the requirements and delivered work may change in the course of the sprint. Likewise, a taxonomist may determine that a new Boolean property needs to be added to the model to support the business use case. If this wasn’t scoped as a technical requirement, it needs to be considered in the functional development.

Epics, Features, Stories

The way that work is expressed in Agile is through epics, features, and stories. Epics are large pieces of work spanning multiple sprints. In an organization based on a quarterly planning cycle, an epic could feasibly span one or more quarters. For example, a taxonomy epic may be something like “Develop a Product Ontology”. Depending on the organization industry, number of products, and how many properties and relationships are involved, an epic such as this might be completed in a few quarters.

Features are the next sized work item, and these typically are significant pieces of work made up of many tasks. Following our epic example, a taxonomy feature may be “Engage with product marketers to define products and attributes”. In this example, there are clearly a lot of steps and individual tasks which need to be accomplished to realize this goal. Again, a feature may span several sprints, but it should not take longer than a quarter.

The most granular pieces of work are user stories (or just stories). Stories define the daily work and should be able to be accomplished during a sprint. Taxonomists don’t always follow sprint timelines, but they can be a good guide for defining whether a story is the right size. Again, in our example, a story could be, “Add preferred labels for 50 top-selling products”. The work is discrete, measurable, and includes some idea of how long this activity may take.

Some of the benefits of using epics, features, and stories in taxonomy development, just as in the parallel software development, are

• Scoping the size of the work appropriately,
• Defining all of the tasks necessary to complete the work,
• Stating measurable, realizable pieces of work, and
• Defining who the work is for and what it will accomplish.

A template for a user story might be something like “As a [role who wants to accomplish something], I want to [what they want to accomplish], so that [why they want to accomplish that thing]” (Agile Alliance). Following on with our example above, a user story may have a simple title like “Add preferred labels for 50 top-selling products” but then include a definition or business goal field with the statement, “As a product marketer, I want to make sure the top selling products are represented in taxonomy, so that product search and landing pages are optimized using taxonomy values for user searches.” Using a template like this makes it clear what the work is, who it is for, and what is intended to do. Although a good taxonomy should include definitions, scope notes, and editorial notes, the larger context around the intent of the taxonomy development can be captured where work is documented and tracked against software development work and organizational planning and goals. Using epics, features, and stories in taxonomy work is also a part of taxonomy governance, documenting why decisions were made and for what purpose.

Kanban

A Kanban board is a feature typically found in software supporting the Agile software development methodology. “Kanban boards, designed for the context in which they are used, vary considerably and may show work item types (“features” and “user stories”), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders” (Wikipedia). Just as in software development, taxonomists can define epics, features, and stories at the appropriate level of work. Since Kanban boards tend to be less restrictive because they don’t necessarily need to adhere to sprint schedules, they may be more appropriate for defining taxonomy workflow items and how they fit within larger organizational bodies of work. “Work items are visualized to give participants a view of progress and process, from start to finish—usually via a kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested. In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce” (Wikipedia).

Especially in complex organizational environments involving many teams (software engineering, the business, the taxonomy team) and systems, tracking taxonomy work in a Kanban board within Agile development software can link non-technical taxonomy and ontology work directly to the technical work supporting its sandbox and production development and delivery for real-world taxonomy-based applications.

Summary

I’ve found that taxonomy development in the context of Agile works best when developing new software functionality. However, loosening some of the tenants of Agile to accommodate taxonomy development is possible. While the nature of software development and taxonomy and ontology development can be very different, taxonomists working within a technical team using the Agile methodology can reap significant benefits.

One, taxonomy work can too easily be abstracted and esoteric, losing its direct connection to business applications, business goals, and importance within complex, metadata-driven environments. Rooting taxonomy and ontology development work firmly in structured, documented Agile processes links taxonomy and ontology work directly to the technical functionality supporting its use in a host of applications. The Agile methodology helps make taxonomy work “real” and understandable.

Two, in organizations in which the Agile methodology is inseparable from quarterly planning and tangible software functionality delivery, taxonomy and ontology work is made visible, and, most importantly, measurable. How often, especially when workforce reduction (layoffs) is imminent, has a taxonomist been asked to prove the return on investment (ROI) for taxonomy work? Using Agile and documenting the work, its intent, and how the work was measured can provide a firm basis for developing metrics and use case examples of taxonomy and ontology work in action.

Finally, taxonomy and ontology development, release, and maintenance can be “squishy” work. Aligning taxonomy work with Agile provides a framework for how to develop and document work, how to measure work in progress and its completion, and how to map that work against technical development. Grounding taxonomy work in this way helps taxonomists stay focused on the immediate deliverables (please add this concept so I can make it live on the website) while remembering the greater strategic goals (develop this ontology so we can develop practical applications with real ROI). Taxonomy alignment with the greater goals and strategy of the organization helps to make the case for taxonomy’s importance in the organization as well as exactly what applications taxonomy supports.

In sum, 15 years after my first foray into Agile, its application and alignment with taxonomy and ontology work is still alive and well.