Coffee and Content: Developing Information Architecture in an Agile Environment
How should IAs use Agile backlogs?
In the July 15th episode of Coffee and Content, Patrick Bosek and special guest Amber Swope of DITA Strategies talk about developing information architecture in an Agile environment.
Transcript of clip:
Patrick Bosek: I think we're all familiar with what a backlog—I mean, backlogs, software development, issues, bugs, whatever. Talk to me about what that looks like from an IA perspective.
Amber Swope: Well, we're gonna—if we want to be truly effective, we have to meet our, our stakeholders and the other team members where they live. And that, that is in your product backlog. Uh, every Agile project has a backlog. What that looks like can look very different depending on, quite candidly, the software you're using to manage it.
There are some consistent things around this. You want to be a peer. You want to make sure that your backlog items are based around deliverables, not tasks. And, and for folks that do not have a formal IA methodology, they might not know what the deliverables that IA can deliver.
And that's where you, as an IA, can step up and say, “Oh, I can give you a, require, an interpretation of the—so, if we have the product story, well there's gonna be a content story that goes along with it. The information architect should work, if there is a, with a content strategist, if there is one.
If not, then that's your job, as the IA, to step in and say, “Oh, well, if, if we're going to, let's say we're doing, um printers and we need in the, the business case is, is that there needs to be a message that allows the person who's operating the printer to know when they have to call support or when they can fix it themselves.” Well, the content story for that is, we have to give them info, info—a really great error message, as well as, if it's something that they can do themselves, we have to give them diagnostic and troubleshooting information so that they can do that.
That's the difference between the product story that might be in the backlog and then the IA’s content story that we need to be contributing.
PB: Is your point around, it should be, uh, deliverables, not tasks, is that more of a general Agile point or is there anything specific—
AS: It's a general agile point, but I think most folks don't think about what IA deliverables actually are—and, and, so, for me, the first thing is, is, what's our content story? What are we going to be judged by? And, so, we need to explain what it is we're going to deliver and what we're going to, what we're going to support the content authors to actually be able to deliver.
And, and, so, in my methodology, I, I like to start off with, “Okay, we're going to do an inventory of, oh, how many error messages do we currently have? Do we have enough so that inventory can be a deliverable?”
Uh, when we get further into the process of the of the project, I'm a big fan of doing diagrams—a visual representation of the content, because a lot of your content stakeholders don't necessarily know if, for instance, if you're creating your content in data, they're not going to know that, somehow, they shouldn't have to know xml. They shouldn’t have to know that you have the right architecture. So, a big fan of, “Oh, well here's going to be our content type or topic type diagrams and here's what's going to be in whatever that package is that's going to get sent to a platform.”
And that conversation, if you do it early, allows you, before you have any code written for a transform or anything else, you can have a conversation with the folks who are doing the transform development and the folks at the, that are there under the pipeline at the delivery end to say, “Oh, well that's, that package is missing something.” And doing that up front, as part of those first sprints in the Agile project, all that can happen, and those are your deliverables as the IA.
Speakers:
This discussion is available on Bright Talk, in the Coffee and Content series hosted by Scott Abel and Patrick Bosek. If you want to learn more about developing information architecture, consider booking ten or twenty-five hours with Amber Swope for coaching.
