Every discussion or training we have held at work lately keeps circling around to the same topic: Agile. Aside from the debates over whether Agile methodology is better than Waterfall overall or in which situations one is superior to the other, analysts who have worked predominantly in a Waterfall world want to know how to do what we do best and still be successful on Agile projects. That is: How can business analysts utilize models to define requirements on an Agile project, where instead of spending months (or longer) using models to elicit and specify all of the requirements necessary to execute the entire project, the project is divided in many small sections and requirements for each section are defined in the time span of a couple weeks?
Requirements still have to be elicited from stakeholders so that the right software can be built. Requirements still have to be documented so that developers know what that right software entails. Whether you are working in a time span of ten months or ten days, using models can simplify that process.
- Is there time for models? Reviewing a diagram with a stakeholder is going to be quicker than reviewing a text-heavy document. Having a visual representation makes it easier for the stakeholder to identify inaccuracies in what is currently defined as well as missing parts. Using models will actually save time. High level models may be created early in the overall project, while lower level models are created one by one as they are needed for items in the backlog as their sprints approach. As team members become used to seeing and reviewing the various types of models you use, they will become more skilled and efficient at reviewing and making suggestions. If you are a consultant on a subject matter you are unfamiliar with, creating and using models is also a very quick method for understanding the new business and systems or processes you are working with.
- What models do I use on Agile projects? Beatty and Chen discuss 22 different models in Visual Models for Software Requirements. It would be extreme to use all 22 models on any single project, regardless of the methodology used for development. Asking what specific models to use for Agile projects is like asking what models to use in Waterfall. Model selection depends on what you are developing and who you are working with, not what development process model you are using. Select the visual models you want to use based on what you need to effectively communicate what you want to build. No single model is rich enough to convey all the information needed in any project – this includes user stories. If you want to write your requirements as user stories, try using a Process Flow Diagram or Ecosystem Map to illustrate the process steps or system interactions, and then write the user stories based on each step or interaction. State Tables and State Diagrams are useful where numerous or complicated interactions cause changes to data objects. The visual representation of each state change makes the process of identifying all triggers of change and potential states easier. The Business Objectives Model is useful early in the project for defining the original planned concept and objects that will solve the business problems, and can also be used throughout the evolving Agile project to make sure any new routes taken are still solving the problems that prompted the project to begin with. A Feature Tree can be used to prioritize the project and determine the sprint order. Low level requirements that are not defined yet can be prioritized by ranking the high level features and then breaking down those features at the lower levels as their sprints approach. These are suggestions – tailor your model selection based on the project you are managing.
How do you use models on Agile projects? Let us know!
