Agile requirements

As many organizations move toward a more agile approach to project management they are finding challenges in breaking the mindset of having to gather all detailed requirements up front. Organizations generally face a wide range of roadblocks when making the shift. Some of the most common challenges that organizations face are listed in Exhibit l.

When polled on the best way to gather requirements, most project stakeholders say “I‘ll know it when I see it” (IKIWISI). Stakeholders want to be able to show you what they want, they want the team to assist them and show them the options that are available. Most often, stakeholders do not know exactly what they want. They need assistance and guidance, and as they start to see the product's potential, they modify the end product.

Exhibit 1 – Common Challenges to Requirements

Gathering all the requirements upfront on a project just doesn't work. Stakeholders need the ability to adjust priorities based on many factors that may not be foreseen at the beginning of a project. Agile is based around the concept of ‘Progressive Elaboration’ — gathering detailed requirements just before a feature is built. Scope is fluid in an agile project, and thus new modeling methods are needed to illicit requirements.

Many project management methodologies use a process heavily focused on gathering detailed requirements upfront. Requirements where documented in text and “signed off” by the customer. Any changes to these requirements are scrutinized and discouraged by structured change management controls. Agile encourages the change in requirements. In order to accommodate changing requirements we know that writing extensive and elaborate documents that will ultimately change, is ‘Waste.’ A more lightweight, and ‘just in time,” approach to requirements gathering is required. The idea of Visual Requirements Modeling has created a lightweight, creative, collaborative and adaptable model to gather requirements with just enough detail while giving the stakeholder the option of changing requirements as needed (Exhibit 2).

Exhibit 2 – Visual Modeling Examples

The Agile Visioning Toolbox

When initiating a strategic project or initiative, determining the level of documentation needed to communicate requirements, processes, and project activities can be a challenge. Balancing the need for comprehensive documentation and eliminating waste, often feels counter intuitive to a team that is comfortable using a Waterfall methodology. Many studies have shown that a vast number of people can receive, process, and communicate information best if it is put in a visual format –“A picture is worth a thousand words.” Visual learning not only provides information quickly, it allows for adjustments and modifications easily.

Most projects, regardless of size, have a combination of three focus areas: Users, Processes, and Technology. When beginning a project, review your Context Diagrams to determine which focus area the project will utilize and reference the guide in Exhibit 3 as a starting point for visual documentation. The key to visual documentation is to provide a format that is easy to understand. The documentation should convey information quickly and spark additional conversations, confirmations, and collaboration. The goal should be to create artifacts that represent your projects and that effectively communicate the business vision.

Figure 3 – The Agile Visioning Toolbox

Exhibit 3 demonstrates a simple toolbox to establish which types of visual artifacts we can create to begin to document requirements visually. This is not an all-encompassing list but rather is meant to be a starting point.

Foundational Tool: The Vision Box

Often when projects are initiated, the vision of a project, and the connection that the vision has to an organization's strategic objectives, are lost. The translation of the vision from the project sponsors and stakeholders is rarely communicated and understood by project teams. Project teams begin projects essentially blind to basic stakeholder objectives and requirements. The team is handed a general understanding of the ‘What’ but not the ‘Why.’ Without understanding the end-goal and strategic objectives, the team is essentially developing blind and innovation and creativity can be lost.

The Vision Box (Exhibit 4) is a simple exercise that helps clearly articulate a strategic project's vision.

Exhibit 4 – Vision Box

1. Step 1: Ask sponsors and stakeholders to articulate their vision for the project. Ask them to focus on strategic objective alignment, project benefits and goals, customer impacts, Return on Investment (ROI), and any other factors that would help the team to develop a product that will ultimately maximize value.
2. Step 2: On a flip chart (front of box), ask each team to design a vision box that communicates the project vision. Add elements such as: Product Name, Graphics and Logos, 3 to 5 key selling points or objectives, and customer testimonials. Customer testimonials are written as fictional quotes from customers who will potentially purchase and/or use your products. These testimonials provide the team with a customer target of acceptance.
3. Step 3: On a second flip chart (back of box), ask the team to design the back side of the box. Add elements such as product description, product features, and operational requirements.
4. Step 4: Review the box as a team. Display the vision box prominently in the team area to allow the project team to review the project vision as necessary.

Foundational Tool: The Project Roadmap

The Project Roadmap is a simple visual timeline that is used to communicate the schedule of development of themes and features (Exhibit 5). The Project Roadmap is not a contract with customers, but rather a communication tool to demonstrate possible project deliverables and dependencies. The roadmap is a project artifact that is updated as additional project details become available. Just like the vision box, the project roadmap should be displayed prominently in the team area.

Exhibit 5 – The Project Roadmap

Foundational Tool: Context Diagrams

Context Diagrams (Exhibit 6) are simple diagrams that are used to analyze stakeholders within a project. A team will determine all the various stakeholders, companies, departments (internal or external), and systems that will need to be engaged through the project life cycle. Stakeholders can then be organized based on the level of engagement that will be required from each stakeholder group. The team can then develop an Engagement Plan on how to engage and communicate with each stakeholder via planning sessions, daily standups, demonstrations, and dependency or release planning.

Exhibit 6 –Stakeholder Context Diagram

User Focused Tool: Users and Personas

When developing a product or system that will be utilized by different types of users it is helpful, as a team, to develop user and persona diagrams (Exhibit 7). These diagrams are used to help identify the types of users that will most likely use the product. Understanding of the customer's goals and objectives can help the project team to create a product that has user-friendly functionality and provides the level of innovation that is expected.

When a team starts the exercise of identifying users and personas it can be helpful to directly contact customers. Discuss with each user their goals and objectives and begin to understand what they would expect from the product's functionality. Remember to not only focus on the technology, but also the emotional and physical needs of each customer. Customer surveys, focus groups, and face-to-face interviews are three easy ways to obtain Persona information.

1. Step 1: As a team, brainstorm all the different types of users who could possibly use the product or system.
2. Step 2: Organize the users into groups with similar objectives and characteristics. Groups of users are called ‘roles.’ Prioritize the key roles that are the primary target audience and which roles will use the system the most often.
3. Step 3: Begin to create several Personas for the key roles. Develop fictional biographies for each persona. Each persona should include any information that will be relevant to the development of the product (i.e., name, gender, age, background, experience, pictures, likes, and dislikes, goals, and so forth).

Exhibit 7 – Sample Persona

User Focused Tool: Use Case Diagram

Use Case Diagrams (Exhibit 8) are powerful graphics that demonstrate the ‘actors’ or users that will be interacting with a system. Use Case Diagrams focus exclusively on new functionality, features, or capabilities that are currently not available. The best time to begin creating Use Case Diagrams is during the visioning phase of a project. As new functionality and/or actors begin to emerge through the project, update the diagram.

As a Use Case Diagram begins to emerge, new themes of work will also emerge, as well as dependencies and priorities. The output from the diagram can then be used to facilitate additional visual modeling tools such as: Release Roadmaps and Dependency Diagrams and Context Diagrams.

Exhibit 8 – Use Case Diagram (www.AgileModeling.com)

1. Step 1: As a team identify, at a high level, the new features that will be available to the actors. Chart them in the middle of the diagram.
2. Step 2: Add the actors that will be performing as inputs and outputs to the functionality.
3. Step 3: Draw lines from actors to the new features
4. Step 4: Logically group similar features together
5. Step 5: Prioritize features

Note: Actors in a Use Case Diagram include: systems, internal customers, external customers, automated processes, and batch processes.

Technology Focused Tool: User Interface Flow Diagram

A User Interface (UI) Flow Diagram (Exhibit 9) is an activity that a team can use to engage with stakeholders to help identify the options that customers will have on a given product. Regardless of the name, these diagrams should be created at a high-level without too much detail and should focus on options that will be available to customers within the product. Generally, these diagrams are created quickly to help clarify a customer's vision and process. The diagram will have the added benefit of getting the whole team on the same page at the same time.

Exhibit 9 – UI Flow Diagram

Technology Focused Tool: Wireframes and Mockups (Exhibits 10 and 11)

Many projects that have a focus on User Interfaces, such as: webpages, applications, and mobile tools have several layers of technology. Often, sponsors and stakeholders have a better understanding of how they want the User Interface to operate and less understanding of the backend technology. Allowing the stakeholders to focus on what they understand and to graphically represent how they want the user interface to function can be an easy way to drive requirements. There are many tools available online that can facilitate these conversations (www.agilemodeling.com and www.balsmiq.com and www.mockflow.com and www.lucetchart.com).

Remember, the purpose of agile requirements gathering sessions is to provide just enough detail in order to build a plan and to have a clear vision of what the stakeholder's goals are. Flip chart and whiteboards can be a great way to sketch out high-level prototypes quickly.

Exhibit 10 –Sample Mockup

Exhibit 11 – Sample Wireframe

Processed Focused Tool: Alternative Path Process Flow Diagram

Process Flow Diagrams are diagrams that can be used to drive understanding of business and technology processes. When developing process flow diagrams there are many options available. Some of the more popular methods are Swimlane modeling, Value Stream Mapping, or Journey Mapping. These diagrams often take an approach of documenting the ‘as-is’ and ‘to-be’ process. Process flow diagrams focus on users experience within a process, and can help determine which processes are adding value, which processes are targets for additional streamlining, and which processes can be eliminated.

During initial requirements gathering phases, teams have a tendency to dive into the details. The Alternative Path Process Flow Diagram (Exhibit 12) is a streamlined version that focuses on the ‘Happy Path,’ or that path that is consistently used by 80% to 90% of the users. Any process that does not fall within these guidelines is considered an alternative path. Alternative Path Process Flows allow the team to focus on the primary process and to identify quickly the key business process in question. Any alternative paths or exception paths are flagged as ‘Spikstories that can be researched in future iterations. www.agilemodeling.com is an excellent resource for additional research.

Exhibit 12 – Alternative Path Process Flow Diagram

Summary

As the agile adoption rate continues to increase, and organizational executives and stakeholders begin to understand the value of an inspect and adapt process, they are continuously looking for ways to harness the power of ‘change.’ They are looking for ways to maximize profit, minimize the time to market, and to provide high quality innovative solutions to complex business problems. No longer are project management mythologies that favor heavy change management processes meeting the ever-changing demands of customers. Visual Modeling techniques are just the beginning step in helping to eliminate waste and to help organizations adapt a more agile mindset.