IA Design and Agile Development: Mission (Im)possible!
Agile Information Architecture
Agile methodology is very popular in technology organizations because it provides a blueprint for organizing teamwork. However, developing information architecture (IA) in Agile can be difficult.
The biggest challenge is that every organization does Agile differently. This means that you have to identify your team’s flavor of Agile. One key variation is the sprint length — some organizations staunchly limit their sprints to two weeks, while other organizations stretch out their sprints to three or four weeks. Another variation is the terminology they use for Agile artifacts. Before you start planning, talk with your team to understand their approach.
Another major challenge is that most organizations know very little about the IA discipline, and therefore start IA development way too late in the process. Because they don’t know how to work with Information Architects, they don’t involve them in development activities. This can result in rushed, incomplete IA design, and extra work later in the project. Ideally, the Information Architect is integrated into the team from the beginning of project planning.
Because IA work involves investigation and analysis, it can be difficult to chunk IA activities into logical sprints, and within each sprint, identify appropriate granularity. The evolutionary nature of IA work complicates the process of planning for multiple sprints.
This article provides methods for Information Architects to plan their work using stories and leveraging product backlogs. Our strategy is to create an IA Sprint Plan that is realistic, manageable, and adaptive.
Create IA Backlog
A backlog is a complete set of prioritized work items, including stories, defects, and other tasks. Build the backlog as you work and use it as a foundation for future work.
Distill IA requirements
To get started, review the product story to identify where the user needs content, define content stories, and collaborate with the Product Owner on the role content plays in user success.
Stories are agile project unit artifacts — how you manage the project. Start with product stories, which focus on everything the user needs, then gradually move toward content stories, which focus on the content your team will develop to fill those needs. All stories provide a clear picture of user requirements in the form of a description of a requirement written from the user’s point of view.
Requirements describe the information and solutions that a user needs from the deliverables. Because one requirement may serve different users, we need a story for each user. This is the template I’ve used for creating stories: “as [whatever kind of user], [here’s what I need or want] and [here’s why].”
The following stories focus on two different users and identify who the users are, what they want to do, and why they want to do it.
Based on these two stories, I can define the first error message requirements — error messages, troubleshooting instructions, and resolution instructions. I can outline more requirements by looking for patterns in error messages and thinking about how messages are presented.
Once I’ve determined the content stories and requirements, I add these artifacts to the backlog. Initially, I’ll focus on the error messages, then use the instruction artifacts to plan future work.
Define and scope IA deliverables and activities
In this step, identify future deliverables to support product and content stories — be specific, leverage available classifications, make iterative activities, and name deliverables based on their final state. This will help you chunk sprints and tasks later in the process.
In the printer error message example, the activities I need to perform include defining the content structure for error messages, specifying metadata from the corporate taxonomy, and developing transform requirements to render error messages. The deliverables that might contain error messages include troubleshooting articles and cloud-based voice services, such as Alexa, that guide users through processes.
Create IA Sprint Plan
Once you understand what you need to accomplish, you can make a plan.
Organize activities into sprints
Chunk your work into smaller units to both ensure you have a realistic amount of work for a given sprint, and to educate others about the amount of work a well-designed IA takes. The following graphic lists, by sprint, the activities needed to develop the error message IA.
Because IA work is iterative, it may take more than one sprint to get to your final design. In this example, I expect to get feedback on the initial design from Sprint 2 and to update it in Sprint 3.
As you organize your sprints, be aware that it’s difficult to predict how long one IA activity will take. Instead of thinking in terms of hours or days, think about your tasks in terms of complexity. Ask yourself: Is this step very complex? Am I building on an existing design or am I inventing something new? Are there related IA items that I need to consider?
Here are a few aspects to consider when determining complexity:
Which IA activities are necessary to support each deliverable?
What are the dependencies between IA activities?
What are the dependencies between IA activities and other development activities?
What process will I follow to complete the activity?
What will the output of the activity be?
Once you’ve answered these questions, you can define the acceptance criteria, and then move onto refining sprints into tasks.
Refine work into tasks
Next, identify the more granular tasks required for each of the activities. Remember, think in terms of complexity rather than time when refining tasks.
Take the end-user content story: “As a commercial printer user, I need a clear error message displayed onscreen when the printer fails. I need corresponding troubleshooting and resolution instructions so that I can quickly get the printer working again and deliver my customers’ order on time.”
Based on the above, I can say: “For a printer, we need consistent error messages that display when a fault occurs.”
An error message alone is usually not enough for someone to identify what happened, know what to do next, and successfully perform the resolution. Therefore, I need to define tasks to develop content that fills each of these requirements, but the troubleshooting design can wait until I finish the error messages support.
Because I like to break the tasks into content-specific chunks, based on the content story and my analysis of the story, the tasks for Sprint 2 might include:
Analyze current error message deliverables (product lines A-C)
Create a diagram of current error message deliverable structure
Identify pattern variations by product line
As you work on chunking, save time and effort by leveraging existing task classifications and naming tasks using verbs to indicate the action performed.
Execute and Demo
The end of the sprint is where we demo our work, close completed work items, and describe results in terms of impact on the end deliverables.
Close current sprint
In Sprint 2, I developed the initial IA support and documented the design in a structure diagram, which means that I can present our initial structure design at the end of the sprint demo ceremony.
In addition to walking the team through the design, I can explain the decisions we made and discuss the impact those decisions have on other teams, such as the transform developers or delivery UI designers.
Plan for next sprint
In some sprints, you might discover something that requires additional exploration. While working with the error message metadata, I noticed that the existing error message numbers are segmented inconsistently. What do the different number segments mean? Can we standardize them? Can we leverage taxonomy values for the prefix and suffix? What systems and people use them? Answering these questions will take time, so I’ll need to revise the sprint plan to make room for extra work.
Conversely, a task might be a lot easier and take a lot less time than you initially planned. When this happens, move on to other tasks and, once again, revise the sprint plan to reflect the work you are actually doing.
Be prepared to continuously refine your sprint plan and expectations. You can only guess how long a task will take, or how complicated a given set of data will be. As an Information Architect working in Agile, you need to be flexible and open to change. Otherwise, you’ll spend too much time managing your Agile artifacts and not enough time doing the work that matters.
Summary
These methods and strategies have helped me develop and maintain IAs while working in Agile. However, because every organization implements Agile differently, my methods and strategies won’t apply to every situation. That’s why it’s important to communicate, simplify, and adapt—talk with your team members and stakeholders early and often to understand their approach to Agile, become adept at chunking your work and be prepared to change your plans at any point in the process.
This article originally appeared in the CIDM Newsletter in May 2021.
If you want to learn more about the relationship between information architecture and Agile, consider booking a one-on-one coaching package with Amber Swope.
