Sprinting in Heels: Getting Started in Agile   

By Hans Aggarwal, M.M.S, CBAP, Consultant, hans@birchisland.ca   
srumHow was I to know that being a Business Analyst (BA) on an Agile development team was going to be like running one of those crazy races where participants must wear women’s high-heeled shoes? For my first Agile project, that is exactly what it turned out to be like, but I am getting ahead of myself. Let’s start at the beginning. 
Launching the Agile project was like any other software development start-up phase where a methodology is customized to meet the needs of the team, management, and the organization. Our first decision was to select Scrum (yes, another sports analogy) as the style of Agile to follow, mainly because there was some experience with it in the team (http://www.scrumalliance.org/learn_about_scrum). 

Here are some other aspects of Scrum that we set for our project:
  • Sprints are development cycles ranging from one to four weeks, with working software as an outcome. In our three week sprints, there was a constant challenge of being able to establish the necessary environments in which versions of the software could be released for testing and demos.
  • Scrums are daily stand-up status meetings that are meant to be short. Due to the size of our team, we held scrums every other day for approximately half an hour and, surprisingly, these meetings stayed on schedule only when everyone stood.
  • Scrum master runs the scrums and resolves any slow-downs, or impediments, in the work. Our project manager was the scrum master, but as his time became consumed with other duties, the BA assumed the role.
  • Product backlog is a list of features the software must contain. Backlog items are estimated and prioritized as part of planning the sprint’s scope or sprint backlog. For backlog management, we investigated the use of sticky notes and white boards (Can you imagine using sticky notes to manage a giant “to-do” list? We eventually had more than 1000 items), but thankfully decided to use the Scrum version of the integrated development environment tool suite already being used by the organization. In our project, backlog management was shared between the BA and the scrum master.  
  • Product owner has the knowledge and authority to make business-value-based prioritization decisions about product backlog items. An individual from the sponsoring business unit was voluntold to be the product owner, and as the person with in-depth knowledge of the requirements and business processes, I took on this role when the product owner was unavailable.
  • User stories are short specifications of the product backlog items, containing only as much information as is required to convey the requirement (A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), v 2.0, page 219). Although user stories are recommended for Agile projects, we used use cases (BABOK® Guide, v 2.0, page 204) because they would help us to better fulfill our reporting responsibilities we had to an outside funding body.
Previously, a project charter and a business process redesign effort had been completed, and with this information we started Sprint 0 to develop an initial set of use cases with related product backlog items and define the software architecture. Sprint 0 was a long “project before the project” but it gave me the chance to practice carrying my BA, product owner, and product backlog manager roles. I was a bit more sure-footed in subsequent sprints, but with the added work of being scrum master and preparing sprint planning materials, there were still some wobbly times. After about five sprints, it was clear that being a BA on an Agile project was about sprinting between roles, driving out requirement details, and helping the team to cross the finish line with working software. And I was wearing out my heels in the process!
Editor’s Note: Stay tuned for the Agile Extension to the BABOK® Guide being published this month for practices, tools and techniques business analysts can use when working on agile teams.