Requirements

3 articles in this category

User Story Mapping - a great tool for business analysis user story mapping
User Story Mapping is something that you probably have heard about if you work as product owner, business analyst or requirement analyst. It is a great tool for quickly break down customer journeys into system areas to map out work. The trick however is to use it where it is useful, which is in the business process when working with business analysis.
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.
 
 

Written by: 💫 Jimi Wikman
Category: Requirements
January 15, 2021
0 comments
834 views
• 
• 

Why are Requirements so difficult to master? reflection
Requirements are very important. In fact I would say that 95% of all failed IT projects can be traced to a poor requirement process. This is baffling because requirements are really not that complicated and yet I see people fail in organization after organization.
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?

Written by: 💫 Jimi Wikman
Category: Requirements
September 26, 2019
0 comments
770 views
• 

15 tips to master requirements to avoid scope creep and costly delays scope creep
Requirements are abused almost daily and it is a fact that most projects that fail miserably do so because the requirement process failed. Lets go over what requirements are and how to make sure you control the requirements and in doing so also control your project.
That is pretty much the summary of what a requirement is, but it's a bit more complicated than that as a requirement is made up of three different parts:
Business need - What people usually think a requirement is. Its a description of a need that should be fulfilled and it can come from the business or the end user perspective. The technical elaboration - The part that is most lacking and the cause for so many failed/costly projects. This takes the business need and extend it with the technical elaborations that make it possible to design or code the solution. The verification aspect - This part is where each part of the requirement is defined in a way that it can be verified with true or false statements. It ensures that the requirement have the right level of clarity. Once you break down the requirement in these three areas you will naturally see the need to involve the correct users in the requirement process. The business need comes from the product owner, who also own the requirement. The technical elaboration comes from the developers and the verification aspects comes from test.
Once the concept that a requirement is a trinity and not a simple request or wish, then you will have come a bit closer to how to get great requirements that are easy to work with and to understand, without having to spend endless hours to formalize them. You can focus on making sure each of the three parts get improved and making sure that there is a natural handover between the requirement phase and development where the development team approves the requirement instead of just inherit it.
In order for this to work there are some things you should make sure you either stop or start doing. Here is my list of some of these things:
Make sure you add business value to your requirements. Requirements cost money and I don't mean when they are being developed. The cost for elaborate on a requirement also cost money so do not waste money on requirements that does not provide a clear value for the product. Make sure you do not forget the "Why" in the user story! The Why often explain why the requirement exist and its what you compare against when deciding if a requirement is valuable enough to warrant the cost to realize it. Make sure you break down user stories to avoid huge requirements. It is easy to end up to high in a requirement, but you need to break it down so it's easy to understand and so it fit within one development period if you are in an agile work process. A requirement is NOT equal to development! There is no 1-1 relation between a requirement and development, just as there is no 1-1 relation between development and test. So unless you will start to write your requirements as a function specification do not expect development to be 1-1 with the user story. Don't refer to other requirements or share user story for multiple development. Each user story is atomic and should be able to survive on it's own completely independent of other user stories. Link to solution designs and things like that, but never to another requirement in order to explain the acceptance criteria. Don't describe solutions. It is up to the developer to decide on the proper technical solution and the requirement should refrain from describing solutions as the technical solution can change based on other development. Never add variables in a requirement by using words like and, or, with, approx. , etc. and so on. Make the requirement clear and free from interpretations. Never use indefinable terms like future proof, faster, user friendly, versatile or robust. Also refrain from using the term responsive as it's also open to interpretation. Don't ramble. Each acceptance criteria should be short and verifiable. If you feel the need to explain the acceptance criteria, then it's probably not properly defined yet. Make sure each acceptance criteria is verifiable. Think of them as check boxes that can be either true or false. If interpretation is needed then the acceptance criteria is not good enough. Make sure that most of the questions from the development team is answered. Instead of repeating the answers over and over, write them down. In order to get this make sure you involve the developers so they can ask the questions right away. Make sure the requirement take the work process in consideration. If you ask for a new component where you want to set a font color for example, then define how you would want to do that. There is a big different between getting a drop list of predefined colors, an input field for hex codes or a color wheel and it will affect your work process. Always let the developers approve the requirement. This ensures that they take over the responsibility and they verify that they understand what you want them to build. Once the development team have taken ownership never alter the requirement by adding or removing functionality. Only clarifications should be done at this stage or there will be mayhem and scope creep. Find the right level! There is no need to go bananas and spend weeks on a requirement unless the organisation need it to get the requirement properly defined. The better each of the three parts of the requirement become at defining the requirement, the faster it will go without loosing quality. You need to find that level where the requirement is optimal for your team. These are just some small notes on what you can do to improve the quality of requirements. I have worked with clients that knew nothing of requirements and did the Agile/Ad Hoc version where they never got a project out in time or on budget. Once properly trained they not only mastered the art of requirements, but they also managed to keep deadlines and budgets.
I aim to write a bit more about this topic later on, but perhaps there is a specific topic you would want me to address right away?

Written by: 💫 Jimi Wikman
Category: Requirements
August 7, 2019
0 comments
765 views
•