ORLANDO–The list of common challenges with requirements gathering on agile software projects can be almost endless, according to Sally Elatta, president of Omaha, Ne.-based consultancy Agiletransformation.com.
These issues can include limited access to stakeholders, conflicting priorities, no clear definition of “done,” too much focus on one type of requirement, and business leaders who don’t know what they want and change their minds often.
But one mistake that essentially derails projects as they start occurs when development teams “jump into the details too early,” Elatta said.
The agile evangelist hosted a well-attended session as this week’s IBM Innovate 2010 conference in Orlando, Flo., to offer up tips on how development teams can easily avoid this trap.
Know the different levels of requirements
Designing the right process for requirements gathering can only start if you know the rules of the game.
“I can’t tell you how many business managers just call meetings with no thought out process for requirements gathering,” Elatta said. She added that every developer and manager at the meeting will likely be taking their own set of notes and every meeting usually ends with no actual decisions being made.
Elatta said the problem is not with the “open discussion” format itself. It’s that companies don’t understand what they’re supposed to be brainstorming.
For an agile software project, Elatta said requirements have to be broken up into four levels.
VISIONING
“For example, if you’re building a house, how many rooms do you want in it?” she said.
For an online job site project, a software team might conclude that the site should feature a job seeker area, an employer area, and a recruiter area, Elatta said. These are all high-level themes, which should be hammered out at the outset of the project.
To help a business stakeholder at the visioning stage, get them to look at the system from a role or user-based perspective. The best way to do this is to use case diagrams and actually draw out the user interface on a flow chart, Elatta said.
For IT leaders at this stage, the move away from a “command and control” leadership methodology to a “servant leadership” approach is vital to building a solid agile development culture. This is crucial, she added, to facilitating a useful flow of ideas during the initial requirement gathering process.
BRAINSTORMING
This stage is the “feature” gathering level and to keep the job site example going, one requirement might include a “resume management” feature,” Elatta said.
Most software teams do a good job at this stage, she said, but there are some ways to get even more effective.
Elatta said it’s important to get teams to collaborate together and even draw pictures or diagrams to get ideas up on the board quickly. “Some companies won’t do this because they don’t have a graphic designer in the room, but really, how much talent do you need to draw a rudimentary chart?” she said.
Post-it notes can be very effective at this stage, as can involve breaking up teams and then later converging them to share their thoughts. “This cuts meeting times in half and it’s a lot more fun than all day sessions where one person is talking,” she said.
Another rule for brainstorming at this stage is to avoid discussing the details of anything. This is especially helpful if you want to ensure your team doesn’t miss any key features. “You’re just trying to generate as many ideas as possible,” Elatta said. “Just think of functionality, don’t discuss it.”
The more you focus on doing this up front, the less “new scope” you’ll have as the project advances, she added.
BREAKING DOWN
This level is where software teams start breaking down the functionality they want in the features. It’s also the stage that is sometimes completely skipped, which often represents a “break down” in the agile project, Elatta said.
“Lots of teams will talk about high-level features and then drop down to details,” she said. For example, developers start thinking about what server the app will connect to in the back-end. At this stage, some features may be too big and have to be broken down into smaller features or “stories,” as Elatta calls it.
A feature that enables a student to register for a college course is very broad and needs to be broken down further before getting into specific details. For instance, one “story” would be the “login” feature, another a “browse available courses” feature, a third would allow students to “view course details,” and finally, a function for “registering for a course.”
Breaking down requirements this way allows developers to tackle each of these features separately and keeps everything testable and development-ready throughout the agile development process.
“The reason you do this is so you can demo and get feedback and acceptance on these features,” Elatta said. If you don’t break down the course registration project, you will have to wait until the entire feature is built before making it usable, she added.
Development teams will also want to ensure the “stories” should be as simple and easy to understand as possible (for example, “As a , I want to ).
DETAILS