One of the top reasons why companies, in particular ones which practice traditional product development, struggle to successfully deliver project is related to the requirements.
In traditional product development, requirements are defined up front as a non-negotiable, very detailed specifications, product must satisfy. Based on these requirements Project Management creates a detailed plan and development teams have a very challengeable job to deliver product which satisfy these requirements. This up-front plan is created when we have at least level knowledge about product, which is very problematic. If during project lifetime, requirements change is requested, it is managed through a very rigid change control procedure. This change of requirements causes lots of dissatisfaction to the development team which goes very much against company value “Delight the customer”. Typically, customers are engaged with company at the beginning of the project when requirements are specified up front and again very close to the end, usually during user acceptance testing (UAT). Unfortunately UAT is the time when customers discover that what has been built isn’t exactly what they wanted and it is too late or too costly for anything to be done about it. In this kind of situation blaming game starts between customer or business representative within a company and development team. Customer says “If you read and understood my requirements better, you would have built what I really wanted”. However most customers really don’t know what they really want until they see product for the first time. Not only that, some surveys very clearly showed that about 65% of product features are barely or never used by customers. On the other hand development attitude towards requirement can be summed up with “Requirements is not well defined or written, they are changing all the time, very often there is misunderstanding between clients and us…”. That all shows real scale of the problem related to requirements.
It is apparent that problem with requirements is closely related with the problem in communication between business and development team. Communication between business and development must be open, trustful, appreciative and considerate. Each side must respect other, neither side should be dominant. If business is dominant scope and dates are forced with little regard for development input. If development is dominant usually business language is replaced by technical jargon, which is nightmare for customer or business representative within a company. We cannot perfectly predict software plan, decades of unsuccessful traditional projects has shown these ways of working to be a failure. What can we do?
We should spread decision making throughout the project, based on information which we have and we should do that often (inspect and adapt mechanism). This is where User Stories come in. User stories are Agile Requirement Technique very often used by Scrum teams. User Stories shift the focus from writing to talking about requirements. User Stories are placeholder for future conversation between the Product Owner and the development team. As said earlier, effective communication is key and User Stories are common language/vocabulary to build understanding between business and technical team.
When we decide to build some product, we should define a product backlog, list of product backlog items (PBIs) or everything which we need to develop for that product. This can be functional requirements, non-functional requirements, enhancements, technical work, removing technical debts, defects… When we create product backlog, we should be aware of the scope for that product but we don’t need list of all detailed requirements up front. Product backlog is prioritised list of requirements. Requirements with higher priority will have more details and be smaller (User stories), requirements with less priority will have less details and be bigger (Epics). Over time, additional details will be collected “just-in-time” through discussions and collaboration between the development team and the Product Owner before and during development. Eventually a User Story is small and with enough details to be ready for sprint execution, where it will be analysed, designed, built, tested and integrated. There is possibility that during the sprint execution, more details will be discovered in conversations between the product owner and the development team. Each User Story should have business value, otherwise why are we developing it.
Scrum Framework considers scope (list of User stories, product backlog) as a leveraging tool or an potential buffer or an degree of freedom that we can use to achieve business goals. E.g., if we’re late, we can potentially de-scope less important User stories. And we can do that because from the beginning we are focused and develop on most important requirements. Equally if during development, we discover important User Story, Product Owner can choose to replace less important User Story with that User Story within the product backlog. So it is crucial that product backlog is prioritised list of User Stories.
This was a brief overview of the Agile Requirements and User Stories business challenges. If you found this text relevant with possibility of improvement your business environment, Agile Requirements and User Stories Training is your best choice. The next one is within the upcoming Agile Month, on April 6, 2016. Early bird registration is in progress.
Towards this topic in upcoming Agile Month, join FREE Agile Workshop on 12th March 2016.
