Over the past decade, agile project management has taken the technology world by storm. Its benefits are far reaching throughout the organization. Upper management gets more predictability, product managers are able to pivot/adjust easily, and engineers take ownership in the process and do what they do best just to name a few. By far, Scrum is the widest implemented of the agile methodologies.

Agile methodologies stress the minimization of planning and requirements. Why?  Because the world has changed. We must stay nimble and have the ability to shift mid-stream if necessary. Also, some drawn out waterfall requirements definition processes can take a ridiculous amount of time. So long, in fact, by the time you complete the requirements/specifications and are ready to start the engineering of the solution, you may have already missed the boat. Market conditions may have changed or regulations driving the internal development may have changed. The definition process can truly become never-ending; great news for some business analysts out there, but bad news for the organization.

Scrum breaks up effort into digestible chunks typically called user stories or work items. For purposes of this post, we’ll stick with the traditional ‘user story’ vernacular. Each user story needs to be small enough to be completed by the engineering team within a single Sprint (a development cycle lasting one to four weeks). If not, it must be broken down further. Per the Agile Manifesto, user stories should follow a specific format of:

As a [role] I want [something] so that [benefit].

For example: As a User I want to be able to reset my password on my own so that I do not need to wait for an administrator to do it.

Pretty precise and, for a good team, little if any additional definition is necessary to implement the ability to self-reset a password. Also, this is absolutely something that can be implemented by the team within a single Sprint.
However, things are not always this clear. For example:

As a Sales Rep I want to be notified of hot deals so that I can close more business.

This may sound simple, but too many questions remain. What defines a hot deal? What type of notification? What frequency of notifications? And so on…

This user story, typically classified as an Epic or Theme, needs to be broken down into smaller user stories. However, you could write hundreds of user stories and still have a degree of ambiguity. That is why using a model-based approach, even within Agile Scrum, is preferred.

Now before all of the agile purists hammer this blog post with hate mail comments because I suggest diverting from the agile manifesto slightly, please hear my case…

I am a huge fan of agile methodologies. User stories are a great advancement from a drawn out waterfall process. But in practice, it is rare that user stories alone are more efficient that using modeling. Especially when dealing with larger projects. Tying visual models, such a process flows, BDDs, DFDs, and UI mockups, to an epic or user story helps everyone involved.

For the Engineer, you don’t have to seek out as much clarification from the product owner or other stakeholder. You have to do less definition and can focus on what you do best: architect and code! Things get done faster and there is much less re-work due to ambiguity issues.

For the Product Manager/Owner, the modeling process is a sense check on its own. I may want a simple sounding piece of functionality but through the modeling process I uncover various intricacies in the proposed functionality that would have gone unnoticed had I skipped creating the models. The greater the complexity of the project, the higher the risk is of missing something. Models help uncover these.

For QA, models give a much higher level of insight into what the intended functionality is. Test plans can be defined and test cases drafted in a much shorter time period.

To some, modeling may sound like we’re reverting back to a waterfall approach. This is absolutely NOT the case. You can embrace sufficient definition and agility at the same time by always striving for just enough. Just enough will vary from team to team and will become less and less over time. Never let yourself get too detailed in the definition process where it is not necessary. For example, our password reset user story above should only require a basic wireframe and simple process flow at most. Don’t go crazy with your modeling if it is not justified as that would simply introduce inefficiency into your process. On the other side of the spectrum, don’t skimp on your modeling where it is beneficial. More time should be spent on models for complex epics and user stories as it will dramatically reduce the overall time your engineering team spends implementing the desired functionality.

Still skeptical? Try it! Over my career I have seen inefficient teams become efficient, and highly efficient teams knock it out of the park by implementing modeling into their Agile process.

As always, please feel free to comment with any questions. Happy modeling!

If you are interested, we have an entire presentation regarding Agile processes, and implementing visual models in an effective way. Check our our ArgonDigital presentations to learn about this and others we offer on a regular basis.