I often see people presenting User Story Mapping as a requirement tool, or even something that is useful for development as a backlog tool. This is usually suggested by business analysts and managers such as product owners, which makes sense because it is for them User Story Mapping is actually useful. Unfortunately it makes no sense for a developer since code are not following a customer journey.

For development, it is often very difficult to map things into a User Story Map. This is especially difficult for backend development where a lot of the work never even is seen by the end user. This causes some issues, not because User Story Mapping is bad in any way, but because it is defined on a user story level, when it is actually a process above the user story level.

For me this process is best used on the business side to map out features by the product owner and the Business Analyst. This is where the User Story Map truly shines, making it easy to understand where in the customer journey certain features live in a visual way. That is not to say that it has no value to a developer, quite the opposite. It is very useful to understand what feature you are working on and where it fit in the flow of things.

It is just not what is important for the development itself.

When it comes to the development itself you still want to have well-defined user stories in the form of work orders and acceptance criteria. Each user story also need to be small enough to be possible to complete within one increment (one sprint) and in most cases you will find that the user stories presented in the User Story Map are way too big for that.

I would actually suggest to not use the term user story mapping since that to me is misleading. I would instead call it User Feature Mapping to avoid confusion.

Try it!

You can use this purely analog by mapping up a customer journey on a white board and then use that with stickies, or you can take advantage of apps in Jira for example. My two favorites are Easy Agile User Story Maps for Jira by Easy Agile and Agile User Story Mapping Board for Jira by DevSamurai. Both are great tools that will give you the tools you need to get started with User Story Mapping.

View full article

Is it really that hard to define considering there is even standards for it, or is it that requirements are just not a priority in most companies....and that is because they are "Agile"?

After I started to look into the different flavors of Requirements I start to understand why things are so very hard to understand for many. There are such confusion about what type of work you should actually do, who you actually work for and what you actually should deliver.

So let us define what a requirement is first:

"A Requirement is a legal agreement between the requester and the performer."

That statement alone will surely get a few people raising their eyebrow for the simple reason that it does not fit in their job description. Again this baffles me that we have so many different work description for a single discipline. My only explanation is that people are confused on what different levels you work with requirements.

If we simply break down the three most common way of working I have seen: Facilitate, Investigate and Document. Then add it to the three common areas of work: Business, IT and translation between the two, then we can make a nice matrix. From there we can see what actual roles people have.

For me I think that anyone working with facilitating meetings as their primary function is a manager. Anyone who just document the need is a secretary. Those two types of "requirement analysts" I see frequently and in my opinion we should make sure that we call them for what they are so people do not think that this is requirement work.

In the investigative category it is common to work in all 3 areas depending on who you work for. Business analysts help business to define their need and IT analysts help IT define their need. This is however not requirements as their final product, but need. That comes BEFORE requirements. In this matrix we can see that the only role that actually work with requirements as the final product are the Requirement Analysts. This makes sense since the definition of requirements as a final product is:

"The outcome of a Requirement is a translation between need and realization of that need."

This is where many fail. I see many, many requirements that are nothing more than a granular break down of a need, but lacking the translation.  Many are often either to undefined and border on a business need, or other times I see technical specifications instead of the need. My theory is that people do not understand what requirements are and who they are for.

We can see this in the delivery of requirements as well. I do not know how many times I have seen people claiming to work with requirements simply dump a bunch of documents on the development team and move on to next project, or next iteration of the project. This way of working when you build walls and throw packages over it is NOT a proper way to work with requirements.

As we can see in the matrix above a requirement analyst sit between business and IT. There she function as a bridge between the two, translating need in both direction to ensure everyone understand and agree on what should be realized. This can only be done with active communication, person to person, and you never deliver a requirement, you make a handover.

I think that this is the key for making requirement processes work: handover and asking development and test to take over the responsibility of the requirement. To ask the most important question there is: "do you understand what business want and can you realize that need with the information you have been provided?" If the answer is no to that question, then you are not done with the requirement.

If you just understand your place in the requirement process and you understand what a requirement is, then the requirement process will be easy for you. If your organization understand that as well, then life will be great for everyone.

So do you still think requirements are difficult?

View full article