Introduction
Change seems to be a popular word in this pivotal election year. When I think about change, I recognize that it impacts each of us in many forms. One of the biggest changes I’ve experienced as a Business Analyst was the transition from working requirements in a traditional project lifecycle to an Agile methodology. The change was introduced to my project team as a management directive with management support.
Our project was an enterprise initiative funded as a multi-year program. The program was comprised of three parallel workstreams with shared releases. Our workstream’s objective was to build out data and data services for the other workstreams and the enterprise to use. The team was made up of experienced Information Technology (IT) professionals and a brand new business unit. We were halfway through the program’s duration when our workstream was called upon to employ Agile methods. The other two workstreams we serviced stayed with traditional waterfall software development, which presented challenges interfacing with each other. The entire program had already completed a Business Architecture phase that outlined the program’s objectives, future state vision, and capability implementation plan.
Before our project embarked on Agile practices, we followed the traditional waterfall approach to Requirements as well. Based on scope defined in the Project Charter, the Business Analyst was responsible for these activities:
- Estimating the Requirements effort
- Negotiating the Requirements duration
- Producing a project plan for Requirements phase
- Conducting requirements sessions
- Documenting detailed requirements
- Managing the requirements baseline via a change control board
- Handing off to the development team and moving to the next phase of the project.
Sounds like the path to successful requirements, right?
Well, as the Lead Business Analyst, I faced the constant challenge of scope being open to interpretation, unreliable subject matter expert participation in requirements sessions, deliverable constraints, and frequent product and process changes. If these were the causes, then the lack of team cohesiveness and communication were the effect under traditional waterfall.
After using Agile practices for over a year and a half now, our requirements process has become responsive to change by planning scope iteratively and committing to smaller units of work. Our project team has daily communication. We are now a cohesive team with mutual commitment and accountability. An Agile environment has also promoted the Business Analysts to become more innovative with our methods and tools.
Getting Started
In the transition to Agile, the first decision we had to make was whether to finish out the requirements gathering effort already in-progress or to halt the requirements phase and make the leap to Agile mid-stream. We agreed to dive in head first. (Note: That decision turned out to be the right one since the use case we left in-progress and incomplete has not been revisited as prioritized functionality a year and a half later!) Management co-located the team, sent the entire team, as a team (IT and Business), to Agile training, and engaged Agile consultants as coaches to jump start our transition. We leveraged the business and technical architecture we had already implemented, used our project artifacts to build an initial Product Backlog, and converted our weekly Change Control Board meeting to Scrum Planning. The Product Backlog did not need to be comprehensive of all the capabilities or features we intended to build over the life of the project. The Product Backlog needed to merely “prime the pump” with more than enough for the first sprint or iteration.
In preparation for our first sprint, we wrote our first stories for the business client’s highest priority features. Features are a form of functional requirements but typically larger than a single sprint’s worth of work. Stories describe the concrete work that implements features that the business uses in production.
Our project team had no experience sizing the work so we played Planning Poker to estimate the value of each story. Agile estimates are based on complexity of the work, not duration or schedule. We used the Fibonacci scale of 1, 2, 3, 5, 8 to size stories with point values. Planning Poker was a subliminal team building exercise where each team member threw down a playing card with their own estimate of a proposed story and then we passionately negotiated the story point value to gain team consensus. We were initially tempted to write the story names that sounded like waterfall phases, Gather Requirements, Design Modules, Test Interface, etc. Then, we challenged each other on Agile principles and created stories like “Implement View Bank Account” with validation of “System Tested in Integration Environment”. Every retrospective, we debated and we improved. The first thing we realized is that 8-point stories are too large. It took months for us to learn how to write stories that were smaller, easier to achieve, and still on-target for the business goals. Once we wrote and estimated the stories for a sprint, the team committed to the amount of work we pledged to complete. The team was truly empowered to plan and deliver.
Agile teams meet daily to communicate progress on the committed stories and tasks. We stand up at the scrumboard where our stories and tasks are posted for all to see. At the 15-minute scrum meeting, we answer three consistent questions.
- What did you do yesterday?
- What do you plan to do today?
- Are there any impediments in your way?
A day in the life of an Agile team member requires that each of us focus on our sprint commitment, be flexible, and apply skills across the team to complete stories.
The Keys to Success
So, what are the keys to successful Agile requirements?
The Business Analyst must work more efficiently and effectively by recognizing the scope of one story at a time, in prioritized order. Story scope is small thus allowing the team and the Business Analyst to gather, document, and actually implement requirements for a narrow but important piece of functionality. As often as possible, I prefer to embed requirements tasks directly within an implementation story. The Business Analyst works closely with the development team and the business client to build a deliverable portion of the product, for instance: a working user interface, a file load process, or a database table. The beauty of closely coupling requirements and design within a story is that requirements cause us to consider certain design options and design options cause us to reconsider certain requirements. A story should only stay open a few days so this is a very streamlined approach. The alternative approach is to have a user story that the Business Analyst leads ahead of actual implementation, possibly one sprint ahead. Sometimes this approach is advisable because more “front-running” of requirements is needed to envision or prepare the functionality. Reasons for front-running may include defining workflows, minimizing risk, managing cross-team or external dependencies, or building out infrastructure in advance of implementation. User stories may be completed to cast a broader net of discussion and help define implementation stories for the Product Backlog and future sprint planning. When trying to determine where to best apply the Business Analysts skills to a story, consider how much is known about a feature, how much still needs to be discovered, and when does the team need the specifics!
Another critical success factor is full team engagement and accountability. Team members no longer handoff tasks and deliverables to each other via emails and project plans. Co-location means that we talk to each other in aisles. Daily scrum huddles the team together. A visible scrumboard requires that we manage the work out in the open. Planning and committing to the sprint stories, as a team, ensures that we are mutually dedicated to success.
We no longer have formal change control of requirements. Within an implementation story, we evolve and maintain the requirements, we design and code the solution, and we test and fix defects before the story is deemed complete. Defects found after the development sprint, for example during regression testing, are tracked against requirements and code. By constantly re-visiting business priorities every two to four weeks in sprint planning, we are able to address changing business needs to support ongoing operations or new business development.
Some factors for successful Agile requirements have remained from the past:
- Project scope still needs to be defined.
- Business and technical architecture still need to be created as a foundation to build upon.
- The Business Analyst still needs access to business and technical subject matter experts.
- The Business Analyst still elicits requirements using familiar techniques.
- Requirements are still maintained as product documentation and are traced to business capabilities and test cases to ensure product realization.
- Lastly, the Business Analyst employs their domain expertise to facilitate and advocate business value!
Conclusion
The best benefit of changing to an Agile approach, that I’ve experienced, is the increased business and IT collaboration. Engaged team members have witnessed the value that the Business Analyst role brings to the project. On an Agile project, the knowledge areas and accepted practices of the Business Analysis Body of Knowledge (BABOK) are just as pertinent to successful requirements and solution delivery.
Agile projects require the Business Analyst skills of enabling business visioning, leading planning and prioritization, and stewarding the iterative unfolding of requirements and design. Business Analysts can rapidly contribute to software implementation by ensuring product fit and integrity. Business Analysts add value to the team by employing business knowledge and analytical skills.
How do I know we were successful in embracing the Agile change? Well, here is my client’s perspective on Agile requirements.
“I no longer wait 10 months from the time requirements are captured to the time they are fulfilled in production. Requirements are packaged in smaller increments and they now reflect my changing business needs.”
Author: Susan Block, CBAP, is Lead Business Systems Analyst at The Vanguard Group in Malvern, PA and VP of Professional Development for the IIBA Philadelphia Chapter