How Business Analysts Use Agile

by Joe Goss, Adjunct Faculty, Wisconsin School of Business Center for Professional & Executive Development
April 4, 2018

If you’re new to developing use cases or process flows, you may be wondering where to start. In the system you plan to document, there may be many roles, the scope of the effort may be unclear, or perhaps there are plenty of complex interactions. It’s easy to lose your way, become frustrated, and give up altogether. I have several secrets for success in these complex situations, and I’ll share one of them with you: Agile can help your team get a good start on developing use cases or process flows.

Where to start

Several years ago, I guided three independent organizations in designing a collaborative process for helpdesk calls including intake, escalation, and resolution. While each organization had its helpdesk, it was critical for these separate companies to give users the distinct feeling that one unified organization was handling all calls, regardless of which one was initially contacted. Adding to the complexity, users might call with a functional or technical issue (or maybe both) and their call had to be routed to the right person. Additionally, the helpdesk process needed to queue issues for support after hours.

Joe Goss, Adjunct Faculty, Wisconsin School of Business Center for Professional & Executive Development

Identify key roles

As you might imagine, the project sponsor and team members were befuddled. No one knew where to start, so the project sponsor asked me to help. Once I understood their expectations, I invited them to begin by identifying key roles in the future helpdesk system. Each “actor” (e.g., tech support, user, and functional support) had a role to play, taking one or more important actions within the system we were designing. Using a flip chart, we listed the title for each actor. After the first pass, I had team members review the whole list and nominate any missing actor roles.

Create process titles

Next, we developed “process titles” in the form of role-action-verb-object from the perspective of each actor. For example, “Tech Support escalates a user’s technical issue to an external resource.” See the pattern? The structured process titles emerged quickly by taking each named actor in turn. After our meeting, I recorded the process titles in a spreadsheet and shared it with team members. As a homework assignment, I asked them to identify additional actors and process titles. This spreadsheet list became our Agile “backlog” of work.

Take the next Agile step

At our second meeting, we added a few missing process titles. We decided to groom the backlog by creating a sprint of the work, and I made it clear we would use this Agile approach to identify two top-priority process titles for our first sprint. I suggested some criteria by which they could prioritize the titles. We started with a few foundation processes and decided to develop the backlog titles in chronological sequence – we’d start the process of the user calling and end with issue resolution. The beginning of the helpdesk process is where we began, creating the first “sprint” of our work. I added a sprint column to our spreadsheet and assigned the top priority process titles to Sprint One.

I knew the team needed an early “win” to build confidence with this Agile approach, so I intentionally restricted the number of process titles in Sprint One, and asked them to include in Sprint One a process title for “training.” They reviewed the backlog and then picked from the list what they thought was an easy one. We now had three process titles in Sprint One.

By the way, this Agile approach works well whether your team is developing process flows or writing use cases. In many ways, these process titles are similar to Agile user stories – small, clear, and distinct.

I shared a written description of the approach I’ve used hundreds of times for reaching agreement on the steps in a process. Armed with 3x5 cards and black pens, the team began working on the “training” process flow. With a bit of coaching, the team identified and reached agreement about the process steps in about 20 minutes. In doing so, we accomplished three objectives:

1. The team learned how to collaborate to identify the steps within a simple process flow

2. They felt good about their early success and built enthusiasm for the work ahead

3. They gave me enough information to create an electronic version of the “training” process, which I used a standard nomenclature from the Object Management Group – Business Process Modeling and Notation (BPMN)

We used the remaining time to develop the other two process titles from our first sprint. Though this work was decidedly more difficult, the team used my approach to develop the processes for the remaining two titles in Sprint One, which took about 35 minutes.

After the meeting, I developed three professional-quality BPMN diagrams from their note cards. Their homework before our next meeting: review and correct the first draft of Sprint One process flows. With their annotations, I had enough time to create a better version before our second meeting.

As you might expect, our agenda for the next meeting included a final review of process flows from Sprint One. Next, we reviewed the backlog and identified high-priority titles for the second sprint. These discussions resulted in changes to the list of titles in the backlog. Some were split in two, some were merged or generalized, and others were simply removed. With the three titles of Sprint Two in hand, team members began to develop each process flow. I monitored and supported their work. After about 45 minutes, we had three more processes completed.

Prepared for launch

We continued this sprint rhythm for a few more meetings but soon realized further development provided marginal value. Though we still had several titles in our backlog, the team discovered it now had enough process flows to launch a high-quality helpdesk process. Herein lies another benefit of Agile – the team was empowered to declare “done.” They had enough documentation to achieve the real project objective – invent a robust business process that customers value without wasting time or money on useless documentation. The team developed only a third of the titles from the eventual list of more than 40.

The steps of developing a process model or a use case are beyond the scope of this article, but you’ve learned how a team took a complex system, broke it into manageable pieces, and worked through a prioritized list of process titles. Some elements borrowed from Agile helped us in that effort.

Joe Goss teaches Developing Use Cases and Process Models for the Wisconsin School of Business Center for Professional & Executive Development. Contact info@uwcped.org for more information.