In my experience, one of the main issues identified as part of the software development life cycle (SDLC) is that the understanding of business requirements (and user stories) is not always translated successfully through development and testing.

Companies might know what they want, and are knowledgeable in their business domain, but may not have the skills to analyse and elicit all the necessary details for their requirements that development and testing teams will need down the line. Therefore, the onus is on the development team (including the business analyst) to make this happen.

Here’s an example: a company wants to update their website with new registration and login functionality.

Breaking this process down into a feature-based delivery:

• The business analyst (BA) creates user stories for the login functionality and defines the what that needs to be delivered.
• The developer (Dev) is responsible for writing the code and determines how the solution will be implemented.
• The test analyst (Tester) creates test cases and acts as the approval that the expected result of the user stories and the requirements have been met.

The following list represents certain aspects of the login functionality which might be considered by a specific role. This is purely to provide perspective to this scenario:

• Password Protection - Dev
• Number of login attempts - BA
• Username construction - BA
• Username validation – Tester
• Password construction – BA
• Multiple logins - Tester
• Forget Username and Password - Tester
• One Time Pins and Reset emailers - BA
• Databases - Dev
• Auto logout - Tester
• Website session data - Tester
• CAPTCHA - BA

Some of these aspects can be missed if the user stories defined by the BA don’t reference or include the relevant business rules or additional details relating to the feature. This is often attributed to the limited information provided by the customer. Developers focus on delivering based on the expectation of the features which are defined, which can result in tunnel vision development. The same can be said where a tester is limited to only creating test cases restricted to ensuring that the conditions of the user stories are met.

Agile throws out buzzwords like collaboration and cross functional teams, though the true value is in the application. I recommend focussing on the basics.

• Include the stakeholders. All stakeholders need to be included in discovery and scoping sessions. Understanding what needs to be delivered holistically improves the ability to define and build the correct solution.
• Ask questions and be involved in the discussions. I can’t recall the amount of times somebody asked a question which leads to discussions and the identification of overlooked or missing requirements.
• Collaborate. Team members need to work together and work off each other’s strengths. There is no ‘I’ in team.
• Communicate. Ensure that all team members are included in communication. Often there are items identified and the information is not filtered through to the team that needs to deliver.

In retrospect, there are many other reasons where projects are not delivered according to the customer’s requirement. Inclusion and recognition for contribution drives positive behaviours, which leads to a cohesive team, and helps successfully navigate a project from requirement to delivery.

About Ryan

Ryan Tolmay is passionate about both business and people. Personal growth is a key motivator in actionable learnings about people, business and technology. With over 15 years of experience in business and technology domains in the banking and telco sectors, he understands the working environment well, allowing him to bridge the gap between different domains and to facilitate as an intermediary. He is passionate about strategic value that elevates people and businesses to unlock their full potential, enabling them to be one step ahead. He believes people are the pillars of any company you work for and when you invest in individuals, they invest in the company.