Agile methodologies are getting a lot of attention now a
days and organizations are keen to adopt the agile for software development.
Scrum is one of the most famous process for agile software
development.
It is assumed that readers have sufficient knowledge on
Scrum agile process and terminology.
In Scrum, all requirements are listed in Product Backlog in a sprint planning meeting, on top the high
priority and at the bottom the ones with lower priority are listed. Team members figure out how many items
they can commit to and then create a sprint backlog, which is a list of the tasks to perform during
the sprint.
The spring
planning is as shown in figure below:
While an agile
approach can be used for managing any project, Scrum is ideally suited for
projects with rapidly changing or highly emergent requirements such as we find
in software development.
When requirements are changing fast, there is risk of misinterpretation of requirements and their functional behavior and also behavior of new requirements.
If there are
complex business rule and complex business scenario then risk of fulfillment of
requirement goes up with each such business case, adding more risk of
acceptance of final product.
This could cause
rework and delay in final product shipment and a long product backlog.
In Scrum, after
defining the Sprint backlog the development activity ,which is called Sprint,
starts . One sprint is usually spans from 24 hour to 30 days.
In such scenario it
becomes very important to have clear understanding of requirements as
development duration is less and there is very little scope to recover from any
rework due to misunderstanding of requirements.
How one can mitigate this risk and can fill the gap between team & product owner to have clear understanding of requirement/functional behavior to develop product as needed?
Behavior-Driven Development (BDD) is perfect answer to this question .
But wait …
What is this and how it can help? Let me explain ..
BDD focuses on
obtaining a clear understanding of desired software behavior through discussion
with stakeholders. Behavior-driven developers use their native language in
combination with the ubiquitous language of domain-driven design to describe the purpose and benefit of their
code. This allows the developers to focus on why the code should be created,
rather than the technical details, and minimizes translation between the
technical language in which the code is written and the domain language spoken
by the stakeholders e.g. business,
users, stakeholders, project managers etc.
Found this definition kind of language
difficult .Lets go into more details and try to understand it together..
Consider the online-store
application. User wants refund in return
of defective product.
Requirement from client will be to
return the money to the user on refunding some article say phone.
Ok, this is fine but what is needed
to implement in software and how client will accept it?
A very obvious question from
development team.
This kind of confusion happens
because user & developer talks in different language .
Developer talks in technical way
and user in their own language for a requirement causing gap in understanding.
How can it BDD be created so that client
and development team are having same understanding.
In BDD language the requirement can
be described as:
BDD provides a platform to
transform requirement into functional behavior .This results in better understanding
of functional behavior of application to both client and development team.
Development team knows what to
implement and client knows what to do in acceptance testing.
This was a summary introduction of
BDD . There are many other keywords available in BDD for all please google it .
And now the million $ question , where to put BDD in a scrum process ?
This is a very important point to utilized the full power of BDD .
The figure above shows all points
where BDD can be plug-in to Scrum methodology.
Lets
discuss how BDD will be useful on all points …
BDD will provide common ground & language to transform requirement into functional behavior in product backlog and to change functional behavior into technical specification to implement.
Many times Functional behavior are related to each other and in software development, team members work parallel on functional behavior linked to each other
In daily scrum meeting ,BDD will
provide common platform to understand each of development activity and will
avoid any confusion and knowledge gap to produce final among development team.
At Sprint meeting , Product owner , Development team & stakeholder comes together and see a demo what the team has produced .
As BDD is in place from Sprint
planning and all stakeholders were involved when defining requirement , BDD
documents become the valid document to discuss final product behavior in user
acceptance .
How this fusion will benefits ….
- Avoids misinterpretation of user stories
- Transform requirement in to functional behavior of the software
- Provide a common platform and vocabulary to understand requirement in better way
- Development team is aware of User Acceptance behavior in advance for all user stories
- As requirements ( user stories )are inter-dependent ,therefore helps in avoiding any confusion among development team
- Spring meetings & daily scrum meetings are more effective
References :
