Overhaul your requirements gathering with an agile development process

Save valuable resources and put an end to frustrating guesswork by extracting a more accurate view of what business users really need.

“We’re not just delivering what the business is telling us they need on a project, we’re bringing some new ideas to the solution.”

—Brett Wood, manager, Data Services, at Xcel Energy

Requirements documents are notorious for becoming outdated and bloated as users, analysts, and architects refine their understandings of business needs. So much so that the final document often bears no resemblance to the actual solution sought by business users in the first place. If this sounds familiar, it is time to overhaul your data requirements process.

Adapting agile development best practices will encourage better and more frequent collaboration between architects and business users. By extension, your requirements will end up more specific, accurate, and up-to-date. In essence, they are more likely to reflect reality.

“In an agile project, we need to find means to understanding the requirements other than documentation,” says Brett Wood, manager of Data Services at Xcel Energy in Minneapolis. “But I’m not saying that agile means you don’t need documentation. Experience will tell you how much documentation is the right amount.”

Wood has found three ways to get business users collaborating with his IT staff on data requirements—and they all focus on in-person communications.

“With our agile projects, we’re trying to break down the barriers between developers and the business. We’re not just delivering what the business is telling us they need on a project, we’re bringing some new ideas to the solution,” says Wood.

He has found three ways to get business users collaborating with his IT staff on data requirements:

  1. Spend time with the business user. “We have working sessions where we shadow business users for a certain day of the month when they need the data,” explains Wood. Sitting next to users and watching what they do and how they do it lets his team see what business users really need to do with data, which can be different from what they say they need.
  2. Use dashboards. “When we show a business user a dashboard, we do a 30-second test to understand how they process that data, what draws their attention, and if it is a good design. Then we refine based on their feedback,” he says. This is an iterative process—one of the hallmarks of agile development—honing user needs each step of the way.
  3. Enable power users. “We are starting to give power users a data lab, their own protected space within our database environment, and elevated rights and tools. This allows them to iterate and experiment with data. The outcome of their proof of concept better shows us what kind of output they’re looking for,” Wood says.

Introducing agile methods to data requirements has benefits that extend past initial project phases. According to Wood, “Business users feel like IT understands what they’re asking for. We also see a much better business adoption and ownership of the solution. You get less of the perception that this is just another IT project.” With adoption and ownership comes quality and governance, two necessary qualities of trusted data.

Read “3 steps to improve business communications and operational excellence” for more on how to raise your visibility, credibility, and influence with business users.

Related content


Shared service through an ICC can result in collective success

Embracing education and continuous improvement shows ongoing commitment to data quality and better alignment with your organization’s common goals.


3 reasons you need to re-evaluate your information strategy

A flood of big data is bringing with it pressure for real-time insights from business users and from security and privacy regulations.


5 ways to approach application integration when acquisition is imminent

Preparing for an acquisition? Mitigate the most common risks during business application consolidations.