It is now well-established, especially for software development companies, that writing down user stories, requirements that capture value to an end product user, is an effective way to conduct any sort of Agile development. (For example, The Scrum Guide). In many simple cases, the user is indeed an end user, whether a consumer of the product or an administrator. Most of the literature uses these user types as examples to illustrate the Agile methodology. Indeed, while crafting user stories, it is relatively easy to visualize the benefits to such an end user.
What if a scrum team is charged with the custom development of a part of a larger system, which essentially involves a scrum of scrums? (Mike Cohn provides a good discussion of scrum of scrums). In cases like this, who then is the user of the component subsystem?
A Perspective for Large Systems
Who would be interested in a proper design of a subsystem? A system architect, for sure. It is the responsibility of a system architect to ensure that the various subsystems dovetail with one another effectively by observing key, time-tested principles of system design:
- Modularity. Modularity can take on many forms, as hierarchical breakdown, layering, or abstractions.
- No cyclic dependency among modules. This avoidance of cyclic dependency is important for, otherwise, we could run into a “nothing works until everything works syndrome!” (For example, Designing Software for Ease of Extension and Contraction by David Parnas).
These principles help us tame the system complexity, which otherwise could overwhelm the programming mind or dissatisfy the end user with the improperly designed system.
The Agile user story crafting now should include principles of proper system design, while adhering to the user story template:
As a <user type>, I want to <function> so that <benefit>.
Consider the hypothetical case in which a sports system needs to be built. The system needs to consider many kinds of popular sports: American football, baseball, basketball, cricket, soccer, tennis, etc. It is quite conceivable that different scrum teams, either serially or in parallel, would focus on one sport each, ending up with system/information architects for each sport. After all, each sport has information vastly different from the others, you would need a specialist for each sport.
As a <System Architect of a soccer module>, I want <a textual search of soccer players, team names, and relevant soccer-related vocabulary in the system's dictionary> so that <no matter what order the search text is presented in an omni-search box, I’m able to find related content in the dictionary>. The search result is a JSON response. Also, the omni-search box must admit input text for any sport.
Note: This user story does not talk about how the output of search information is to be presented, if at all; it expects a JSON response, that can then be subsequently combined with any other information. That would be the content of another user story.
It goes without saying, the decomposition of user stories themselves would do well to follow scrum-tested principles of the INVEST mnemonic.
So, what did we learn so far? The ‘user’ in the Agile user stories may not necessarily be the typical end user. Sometimes it could be a System Architect, who is best suited to determining the user story content.
Everything you need to know about outsourcing technology developmentAccess a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.