Slice by Happy vs. Unhappy Path
Any feature or method that we add to our solution will have happy and one or more unhappy paths. The happy path describes how the feature will behave when everything goes according to plan. If there are any errors exceptions or omissions then the unhappy path is taken.
Consider a standard authentication User Story for a website with members only content:
As a member I want to log in with my account so that I can access members only content.
If we assume a standard login procedure we can identify a happy path and several possible unhappy paths.
As a member I want to log in with my account so that I can access members only content (Happy)
As a member I want to be able to request a new password when my login fails, so that I can try to log in again (Unhappy)
As a new member I need the option to register a new account so that I can access secured content (Unhappy)
As a site owner I want to block users with 3 failed log in attempts in a row so I can protect the site against hackers (Unhappy)
As you can see the unhappy path describes omissions or exceptions in our process. By identifying the various happy and unhappy paths we ensure that the delivery team fully understands the functionality required by the customer. The more detailed and granular user stories also provide an opportunity for more accurate Acceptance Criteria for each sliced user story. The sliced User Stories also give the product owner the opportunity to prioritize functionality at a more granular level. For example, in the first release there may only be a few users so locking accounts after 3 failed logins may not be important yet. The password reset feature may also be overkill in the first release as someone in Operations or Support can easily reset a user’s password upon receipt of an email request from the user.
Stay tuned for 6 more methods for slicing User Stories…