How to Do BDD and Agile Well for Your Mobile App Project

In a previous post I wrote about how Jobs to be Done theory can be used to develop a clear and powerful mobile strategy. But once you have this mobile strategy in place, and have developed your stories, how do you then execute BDD well in an Agile environment?

Going from a waterfall, fixed-price agency to where we are now with Agile has taken seven years. But over those years we’ve grown and adapted our processes to eliminate pain, decrease complexity and increase efficiency for ourselves and our clients.

It’s important to remember that no process is set in stone. Any process is a living, breathing thing that grows, evolves and can even die when it’s outlived its usefulness.

But here’s the current overview of how we effectively integrate BDD and Agile into our client-services business model.

1. Prioritize

Once you have your initial stories written they should be prioritized. There are a lot of great tools including lightweight ones like Trello, or heavy duty ones like LiquidPlanner. We currently use Pivotal Tracker. We’ve loved and abandoned (chabudai gaeshi) five project management tools in our seven years of operation. Cards on the wall is a classic option, but not one we’ve embraced because even if the mobile app team is colocated the client invariably is not. Cards on the wall can’t help the client which in turn makes them feel disconnected them from the rapid agile flow and creates a lot of unnecessary communication problems.

But regardless of the Agile tool we are using, once we have the stories listed by priority we determine the minimum viable product (MVP).

2. Estimate

Depending on the project size and the number of stories, you may want to estimate just up to the MVP. If stakeholders need a higher level estimate for all known stories, everyone on the team should see this as an order of magnitude estimate, with the clear understanding that many changes in the product will occur in the future.

As new MVP stories are added, you’ll want to ensure these are estimated quickly, keeping everyone on the team aware of the total number of sprints needed to release your MVP. If you need more sprints but there isn’t enough time or enough budget, you may have to move the lowest priority MVP features to a future release.

Execution

3. Back Log Audit

This is a simple but key step where the backlog is reviewed by the team to ensure that it’s current and properly prioritized.

4. Load the Sprint

For mobile we prefer to work in three-week sprints. This allows us enough time to build wireframes, comps and establish the Technical Architectural plan, develop the needed features, showcase the release candidate and get stakeholder feedback, revise, bug fix and release at the end of the sprint.

5. Three Amigos Stories to Scenarios

As a BDD shop, the three Amigos (The Product Owner, Developer and QA) unpack each story and identify the specific scenarios (including the happy path/sad path) needed to satisfy each story in the sprint. In addition to providing the team a clear vision of success, the scenarios become automated test scripts which are run throughout the duration of the sprint.

6. Wireframing, Comping and Technical Architecture

While development is starting, the important ground work should be laid. The User Experience team meets with Development and the Product Owner to determine how the interface should be restructured to accommodate the new features. They then incorporate this knowledge into the existing wireframes and adjust comps accordingly.

Meanwhile, the Development team and the Technical Architect research what will be required to implement the new features and strategize on how to incorporate the new code into the existing product.

7. Development

Development has full BDD scenarios to start coding/testing against – even before they integrate the UI. This allows for “headless” testing of model objects, API, etc. And since tech dev was in the three amigos meeting there is significantly less risk of programmer churn while wires, comps and technical architecture strategies are being developed or throughout the sprint lifecycle. BDD enables maximum coding velocity throughout the entire sprint. 

8. Release Candidate Demo/Testing and Bug Fixes

At this stage, the sprint’s release candidate is demoed for all stakeholders. Stakeholders are walked through each feature slotted for release in the current sprint. Small changes are implemented in app immediately, while larger changes are added to the backlog for prioritization. Finally, stakeholders determine if they would like to release the app onto the app stores or hold the release, adding another sprint of features.

9. Release

Whether it’s the first or the 15th sprint, we prepare the mobile app for release onto the app store. Features are completed within a sprint and do not span multiple sprints. By finishing features within a sprint we can keep the project flexible as priorities and features invariably change.