The Service Blueprint: A Smarter Approach to Modernization
Modernization isn’t just about upgrading technology—it’s about upgrading your organization’s ability to change and adapt.
This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
UDig’s Client Services team has partnered with our Engineering team to revamp the way we conduct client requirements gathering. This partnership has allowed for an increased universal understanding of a client’s wants and needs through intuitive user story development, consistent stakeholder engagement and workflow-centric design. While the benefits of such a practice are apparent for project management and development, our team discovered a few hidden benefits of this practice as it matured.
Requirements gathering is certainly not a new concept. Engaging with clients early and often from the inception of a project builds trust, prevents rework and provides direction for the team. In an Agile environment, development teams need requirements early to start design quickly. As a Project Manager, it is critically important to solicit accurate requirements in a format that makes sense to the client, designers, developers, engagement managers and beyond.
The cornerstone of this process has been the user story. User stories capture what a system user needs to do in a format that any stakeholder throughout the agile cycle can understand. UDig has long employed this methodology to translate functionality into business language but has recently employed a new all-inclusive strategy.
Enter the Gherkin format for user stories. The plain language parser, Gherkin, was created for the Cucumber software tool to conduct acceptance testing in a behavior-driven development (BDD) method. The core concept of BDD is that software development must be managed by interests both technical and business. This balancing act makes the Gherkin format perfect for structuring user stories. Gherkin is written using the following structure:
GIVEN some context
WHEN some action is carried out
THEN a particular set of observable consequences should occur
Here is an example of how gherkin can be used to document the feature of adding a new item to an online shopping cart:
GIVEN I am a logged in user
WHEN I go to the item page
AND I click “add item to cart”
THEN the quantity of items in my cart should go up
AND my subtotal should increment
Any scenario can benefit from this methodology as it provides a logical structure that developers can easily understand, project managers can easily track and clients can easily verify and tweak.