Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

In part one of this miniseries, we introduced formal Use Case Analysis and a simplified version called Use Case Planning which fits a rapid, iterative development process. That post went over the high-level concepts, and explained how this planning method will help you catch problems with your design before you start to implement.

In this post, the final post of this miniseries, we’ll step through a concrete example so you can see how to put Use Case Planning into practice.

After reading through this post, get access to the 45 minute video tutorial complete with slide deck and instruction from Ben in our Engineering Lunch Series. Be a QLer for the day and see what we're teaching our engineers in our semi-monthly engineering lunch series. Sorry, we don't buy the lunch but you do get the tutorial for free!

Read More

Happy, Sad, Evil, Weird: Driving Feature Development With Use Case Planning

When building software iteratively, feature planning has to be done early and often. But it can be a complicated process due to all of the stakeholders involved, each with different viewpoints and goals.

What's more, it's easy to overlook key behaviors of a feature, which can lead to expensive and rushed code later. It's usually intuitive to figure what should happen when everything goes according to plan, but what about edge cases? What should happen when a user supplies bad data? A hacker launches a malicious attack on our application? What about when chaos makes the whole system unstable?

In the first post of this miniseries, we'll take a look at one way to get everyone's voice heard in the planning process, including the product owner, developer, designer, and QA engineer. Using this approach, teams can draw on their diverse perspectives to tease out a detailed blueprint of a feature that costs less and performs better.

Read More