The Journey from Business Requirements to Production Code

I am an advocate of using agile processes to tackle undertaken projects to implement custom code solutions. But agile need to be well understood by all parties including solution provider's management, project management teams, development teams, DevOps, as well as customers and their internal teams allocated to provide business requirements and execute the project from initiation to closure.

Agile Project Management

It should be well understood that agile processes do not contradict with project management processes, knowledge areas, or approaches. In fact they compliment each other.

There will continue the need to conduct project initiation, to have charters provided, to scope an overall project, and to carry out all those processes we know from PMI and PRINCE.

It is even agreed on within the community that agile is not a method at all, but a set of concepts if used will enhance the communication among all parties, reduce time to market, and assist providing quality production code.

Business Requirements

Business requirements are not initially provided as customer stories, they are usually given in a specially formatted document known as business requirements document or BRD.

BRD is an upper level set of scripts defining the needed functional and none functional requirements required to accommodate for the original business need. BRD needs to be detailed into a more specific set of requirements known as software requirements specifications or SRS.

To SRS or Not to SRS

One of the first initiatives to incorporate agile approaches into software development projects recommended jumping from business requirements directly to build customer stories skipping the detailing as SRS in sake of a what used to be called light weight documentation.

I do not want to eliminate that possibility at all; but would like to emphasize on the fact that this approach depends on the complexity of the project and the depth of business requirements illustrated in a BRD.

Not all projects succeed when skipping the detailing of a BRD into an SRS; as the requirements mentioned in the BRD are barley upper level and do not get to the level of binding specifications between customers and solution providers.

If the project is declared as complex with wide spectrum business requirements, it is better to get into a systems requirements phase or SRP that leads to a fully detailed SRS that becomes binding to both the customer and the solution provider.

For simple projects where there is no complexity and the spectrum of requirements is so limited and understood by both parties; the jump from BRD to customer stories can be used provided that it is explicitly agreed between the two parties.

Translating to Customer Stories

Once either an SRS is ready or it is agreed to skip and go ahead with customer stories; a product owner or PO who may play the role of the business analyst or BA as well can start translating a BRD into a set of customer stories known in agile as product backlog.

The biggest mistake that you can make as a PO when translating BRD into customer stories is to play it solo!

As the name indicates, customer stories are stories told by a customer represented by different business domain personnel. POs are story tellers who use a special story telling language to translate what customers tell to a notation that is well understood by both the development team and the customer's user acceptance testing or UAT committees.

There are many standard formats and recommendations for how to write customer stories. It is important that whatever standard you use needs to be explained to all parties including the customer, development team, DevOps, and specially speaking the customers UAT committees.

Whenever I played the role of a PO, I used to utilize the SRP phase of an undertaken project to conduct a series of workshops with the customer committees representing different business subdomains to go over their subdomain related business requirements as mentioned in a BRD to elaborate on them and listen to their stories.

Then I used to document those stories in the agreed on customer story format and notation.

A successful PO is someone who can play the role of a catalyst in workshops where subdomain committees are allowed to declare their needs bounded to the scope documented in a BRD.

In the case of complex projects where an SRS is generated during an SRP phase of a project, customer stories can be derived from an SRS document trusting that the BA has reached an explicit binding consent of customer on whatever is mentioned in that SRS document.

Building Unit Test Code

Unit tests are a special code blocks and functions used in a test driven development or TDD approach to bridge between customer stories and production code.

While traditional waterfall approaches used to wait until the production code is ready to conduct different test types based on test scenario scripts written by test and quality engineers; a TDD requires test and quality engineers to produce unit test code blocks and functions that turn all red when executed against production code until the production code fully satisfies all unit tests and the light turns all green.

It is obvious that you cannot execute unit test code against a code that is not written yet and that you cannot make sure that the unite test are themselves bug free unless this is carried out iteratively, elaborately, and collaboratively between test and quality engineering and development teams.

Concise Production Code

As said that "code is poetry", production code needs to be concisely created to only satisfy a given set of unit tests, no more no less. If a developer can write a single machine code instruction - not even a statement - that turns a red light to green when executing a unit test; that would be it.

Programmers must be encourages not to add any extra code beyond satisfying the written unit test code.

If production code did not meet an original customer story; then the unit tests needs to be modified and amended before production code is altered and not vice a versa.

A coder reference should be the unit tests while not ignoring understanding the customer stories.

Cyclic Workflow

As the banner diagram above shows, the relationship among the four stages is cyclic in terms of workflow, and each stage leads to the next by default with potential of going back from the end to any of the previous stages.

This emphasizes on the elaborative nature of agile project execution and complies with a what so called domain driven design or DDD.

While an agile iteration or sprint gets executed to satisfy one or more subdomains; requirements of other subdomains may not be recognized within that iteration. Once production code reaches out to customer UAT committees interactions among different subdomains may and will affect details in customer stories of other subdomains within the same business.

This is totally healthy and should not cause fear or panic to any of the two parties. That is why we mentioned that the agile approach and the used standards and formats should had been agreed on from the beginning of the project and should had been emphasises on during scoping, planning, and SRP phases.