Everything you ever wanted to know about the News Apps process

I had never thought of the News Apps team as a particularly secretive group, especially given our insistence on transparency. We grant access to our Google Docs to practically anyone who shows interest. We’ve held demos and lunches to introduce the team and our work to colleagues. Our code is mostly open source and accessible in GitHub and, well, we post to this here blog you’re reading. I’d say we’re doing a pretty poor job of cultivating an aura of mystery.

Yet that aura of mystery persists. Part of this is inevitable—in a company as large as the Tribune Media Group, few employees can keep tabs on the activities of departments other than their own. And I’m sure outside the company even fewer people know what the News Apps team does. Sure, some folks may recognize our work, especially projectsthat have receivedwidespread media attention or open-source tools we’ve built that other developers have adopted, but who knows how the team actually works?

Oh, wait—I do! I’ve found myself explaining who we are and what we do with some frequency lately, so I thought it might be useful to explain our process here, in an easily-shareable blog post. Then you, too, will know how the News Apps team works…and if any part of our process sounds useful, feel free to crib it for your own team!

We practice agile development, with a lowercase a. While there are more structured forms of capital-A Agile Development (terminology! acronyms! certifications!), we stick to the basics as outlined in the Agile Manifesto and keep our process as lightweight and straightforward as possible. We loosely follow the Menlo Way, adopting some key practices (like prioritization of personas) and discarding those elements that haven’t proven a good fit for our team. We’re big fans of eliminating unnecessary steps while ensuring everyone involved in a project has the information they need to make decisions and accomplish their tasks.

The team typically follows the same steps for all major projects. Small projects, bug fixes, and improvements to existing projects often skip some or most of these steps, depending on the scale of the work. However, from start to finish, this is our full process.

1) Idea/request

We receive a request for help or one of our team members suggests a project idea. Excellent! Ideas are good, and we like to help. This is the ideal time to loop in the project manager and/or the team director—approaching one of them directly is likely the fastest way to get the gears moving.

2) Description/documentation

But we need to know more about this idea. We request a document from the stakeholder explaining what the idea is, what need it fulfills, who the audience for the product would be, etc. Any available supporting research is great, too. (We have a doc explaining what we need for stakeholders to use as a guide.)

3) Evaluation

Once we receive the requested information (and possibly ask a few followup questions), we can start to evaluate the potential project. What does our schedule look like? What deadlines are involved? Does it sound like there’s a real need for this product? If we think it’s something we should pursue, we let the stakeholder know we will be able to tackle the project and we start planning in earnest.

4) Research/personas

Based on the research the stakeholder provided, we do some additional digging on our own and write representative personas for key audience members and stakeholders. These personas should feel like real people; they will help us put a human face on the project and make sure everything we’re building is *for* either a user or stakeholder. Once these are written, we check with the stakeholder to make sure the personas are accurate representations of the relevant stakeholders and target market and make any necessary adjustments.

Meet the (fictional) Dennisons, a sample persona. Sorry about the tape glare.

5) Prioritization of personas

With the stakeholder, we determine who our key personas are. We draw a bullseye and place one primary persona in the center ring, two secondary personas in the second ring and three tertiary personas in the third ring. The primary persona is our key concern; nearly every feature we ultimately build should satisfy a need for that person. The other personas on the bullseye are important, too, but our focus is that primary persona. If we try to build something for everyone, our product will be unfocused and ultimately satisfy no one; if we focus on that representative primary persona, we ensure we’re building something useful for a specific market.

And these are our personas prioritized on a target. Yeah, my circles are a little rough.

6) Needs/wants

With the stakeholder, we brainstorm a list of each persona’s needs and wants as they pertain to the subject matter of our project. These are not features or tasks, simply what each person ideally wants. (A developer persona, for instance, might want a stable site that doesn’t require constant maintenance. If the project is a shopping site, for example, a suburban mom persona might want to know which stores in her area are having sales.)

7) Features

Once we have a list of each persona’s needs/wants, we (with the stakeholder) make a list of what features would address each of those needs/wants. It doesn’t matter how outlandish these features are—we know we’re not going to build them all—but we want to make sure we don’t overlook anything. For convenience, we write each feature on a separate index card.

8) Prioritization of features

With the stakeholder, we sort all the features into piles: Must Have, Really Want, Nice to Have and Meh. Must Have features are the features that are absolutely necessary for our minimum viable product, Meh features are things that we’ll probably never get around to building and Really Want and Nice to Have features are pretty self-explanatory. When we begin work, we tackle Must Have features first and work our way through Really Want and Nice to Have, depending upon how much time we have until launch.

9) Manifesto

Once we’ve established our audience, figured out their needs and determined what features our product should contain to satisfy those needs, we write a brief manifesto. Despite the intimidating name, this is just a short document that describes our high-level vision for the project: in brief, what features it will include, how it will be used, what key needs it will fulfill, etc. This isn’t a detailed, in-depth project requirements document, more of an overview of what we plan on building and the rationale behind the project. It’s written like an essay, vision statement at the top followed by narrative that describes the personas and key features. The narrative section is followed by the prioritized list of features. After we write this document, we will share it with stakeholders and incorporate any necessary input. Once we make any necessary adjustments, it’s important that all stakeholders sign off on the manifesto; this ensures we’re all on the same page and gives us a document we can refer to if new ideas or feature requests are proposed at a later date.

10) Kickoff

We have our personas, our prioritized list of features and our manifesto. Now is the time for an official kickoff meeting with stakeholders to make sure everyone’s on the same page. Whereas we try to keep brainstorming sessions and many other meetings quite small in order to move quickly, this meeting will likely involve all possible stakeholders. Any feedback? Reconsidering the priority of some features? Let’s discuss. This is also a good time to reconfirm deadlines and manage expectations in order to avoid confusion down the line.

11) Tickets

We can start entering tickets in Unfuddle any time after we’ve prioritized our features, but we need them in the system as soon as we kick off. In this stage, we make sure that all technical tasks encompassed in the features are entered as separate tickets. One feature may be broken down into several discrete tasks, each of which should have its own ticket.

12) Project plan (milestones, iteration reviews)

Once we’ve entered tickets in Unfuddle (or simultaneously), we need to make sure we have our project plan mapped out. The number and complexity of tasks, the number of team members working on the project and the amount of time we have to work with all figure into how many iterations we’ll schedule. Each iteration is typically a week long and culminates in a weekly iteration review with the project manager, the developers working on the project and the relevant stakeholders.

13) Development/iteration reviews

In order to begin development, we need to schedule tickets and assign them to team members. At the beginning of every project, we set up recurring weekly iteration reviews with the development team and the relevant stakeholders; in these iteration reviews, we cover:

what we did last iteration

what work was scheduled that we didn’t get to

what’s scheduled for the next iteration

any questions/comments/blockers.

These weekly reviews keep everyone in the loop and ensure we all have the opportunity to flag any potential issues in a timely fashion. Everything is described in a document and shared with the meeting attendees a few hours before the meeting so we can spend the meeting time giving a demo and collecting feedback.

14) Launch

Not on Fridays, just in case…. We always make sure to get stakeholder approval on launch dates and request any necessary support/changes from other departments as far in advance as reasonable. Most if not all of the developers assigned to a project should be in the office on launch days and should be prepared to stay late if necessary.

15) Post-launch iterations/support

Depending on the scope of the project, we will likely schedule at least one post-launch iteration of work and iteration review in order to make bug fixes and adjustments. Sometimes (particularly if we’ve launched a project on an aggressive timetable) we will plan on making multiple iterations’ worth of further improvements; we continue to schedule weekly iteration reviews with stakeholders as long as it’s a project with ongoing development (other than simply a support issue or bug fix here or there). Once we complete any post-launch development, we are still available to provide support on an as-needed basis. No further iteration reviews are necessary at this point, unless extensive additional development has been requested, in which case we will evaluate the new requests and schedule accordingly.

Situations where we don’t use our full process

For small projects or tight deadlines, we have a document template that encapsulates and streamlines steps 2-9. Someone on the team will complete this document, which the team director and/or project manager will review before determining if we can take on the project. If it’s a go, the project is scheduled and kicked off as soon as our schedule allows.

Bug fixes go straight into an Unfuddle ticket and are prioritized. Feature requests are vetted by the director, the project manager or a developer and either turned down or entered into an Unfuddle ticket and scheduled depending on priority and team availability.