Scrum roles and users

Last week I was reading some material on scrum, particularly on agile requirements acquisition for a post I plan to publish soon. I was reviewing the User Stories Applied For Agile Software Development book by Mike Cohn, definitively a recommended reading. 183072549

I like the Capt. Obvious facts about software development and how often we need someone to constantly remind our teams about those allegedly obvious statements. This is precisely the case, do you ever forget to target your efforts to what the user demands? I am sure you do, I also do

Writing user stories is the way to formalize requirements in some agile methodologies as scrum, the well-known formula As a role, I want goal/desire so that benefit. This definition itself forces us to think in the user roles and pushes us to go for a genuinely user-driven development

The user roles in software development

Having worked in web environments, quite frequently I see requirements written from at most two perspectives, logged in user / anonymous user. In some projects only the registered user is taken into account, lowering your chances to conversion in a bad marketing strategy against known patterns as ecommerce register-at-checkout pattern, or mobile/social apps signup. It should be obvious that this is not enough. Our system will be used by different users with a number of user profiles. Losing user roles will lead to an incomplete or just wrong product

When gathering requirements it is really recommended to always look through the user prism. The user stories enforce this by their mere definition

User roles can be defined during some sort of brainstorming. A user role must have clear attributes and objectives. You can add this to the role definition. Some roles may overlap as belonging to a category. That is great as it will enrich the model.

For instance imagine a blog network software system. At first you may think of «readers» and «writers». At some moment you decide that for your business there will likely be «corporate writers». A single blog «writer» and a «corporate writer» who can work in different blogs for money have different needs, then it makes sense to have both roles well defined and think from their perspective when writing a particular user story. However this does not mean in any case that your product should explicitly reference these roles

The role definition should be present during the product development, with a clear profile and a goal to achieve using the product.

After creating the roles you can just abstract them to a smaller set and ideally look for real users corresponding to these roles, or create a detailed fictional personas. You can even try to get information from some other source, just don’t believe that you can grab the role mindset by yourself

Getting stories from users

It is important to have a user base for all of the roles identified. A good user pool will help you to stay targeted. At the beginning you may believe it is just too much to cope with, however don’t forget that we talk about agile here, refine as you go having a clearer idea. The team will auto-adjust through the building process. Just remember to give the user enough room to explain by making no closed questions without implicit answers.

When you can’t work with users

Sometimes you just can’t have access to the final users. These are bad news as it is the base of users who will ultimately define the project success. Maybe there are managers of any kind in between, maybe the users are outside your company or don’t even exist (potentially they exist but you haven’t done any research). In my experience if users are unavailable you must work with a user proxy. Some kind of entity between you and the users. For me, I have had to deal with

  • High level manager is not a user, nor will be, however has the power to micromanage the project. You could end up building a very nice (and bloated) dashboard or good management tools but a not so good for daily usage which will basically affect the productivity
  • Mid manager, being responsible of the team using the system, also dangerous as his expertise as manager does not necesarily give a knowledge on day to day of a system usage
  • The sales department has a to deal with customers but much of this interaction happens outside the scope of the project. Probably you will prioritize large expected outcome for future sales, or working for past lost sales
  • The helpdesk department is a good source for bugs and existing’s system lack of functionality, not so good for customer-satisfaction requirements
  • The money guy, will pay for the system but not use it
  • Professionals and experts, a good chef not necessarily knows about building a site about restaurants but can help

All these people inside or outside the organization, sometimes playing chicken roles, can be valuable when their real-world roles actually exist as user roles (rarely happens). When this is not true still can be part of the process, by giving out information or as a decision-maker for the group he/she is representing, but remember that ultimately will be the product owner’s responsability that you have built the system
that needed to be built, even if that implies assuming that the product the user demands is not the real product you need to develop

Next to come, how to turn requirements into fuel for the sprints. Remember to trust the user and when in doubt, simply go for simplest, clearest and best defined user stories