How a team builds a software application largely comes down to the type of project management methodology it employs. At ZEAL, we use Agile principles to inform our project management, namely with epics and stories.
I love pictures, so let’s paint one together. Imagine your application as a three-ring binder. Inside that binder are all the guts of your application (APIs, business logic, design systems, etc.).
Now imagine if you just stuffed all the information about your application into that binder without any organization. It’d be a mess, and you’d likely lose sight of the purpose of your app.
So you go to your local office supply store and pick up some page dividers. Those dividers become the major sections within your binder, with relevant information bound neatly in between each divider. Now that seems more manageable, doesn’t it? Organization for the win!
For the Software Residency app, our team created several dividers for our binder. These dividers, or epics, formed the major sections for the entire scope of the app informed by user research. Inside each epic, we then wrote user stories that reflected our user’s needs.
For example, we knew that our users would need to be authenticated in order to access their accounts. This goal became our “Authentication” epic. The elements of authentication—logging in, password resets, etc.—then became our user stories. To illustrate, one of our user stories was “In order to gain access to the application, as a user, I need to login.”
Now for the fun part! Here are a few things to keep in mind when writing user stories:
User stories should include a “why”, “who”, and a “what”. Consider the following story:
In order to gain access to the application, As a user, I need to login
The first statement provides implementers with the purpose of the story (”why”). The next statement details who the story concerns (”who”). And the final statement outlines what the target user hopes to achieve (”what”).
Some Agile teams will put the “why” clause at the end of the story. At ZEAL, we believe that starting with “why” (thanks, Simon Sinek) is a better practice. Doing so puts the reason for the feature at the top of our minds and “allows developers to make the implementation tailored to the business needs.”
By keeping stories small, software teams can accurately measure velocity, the sum of story points in an iteration. Using velocity estimates, project managers can then determine how long similarly pointed stories will take in the future. Small stories also allow the team to make more visible rapid progress, which in turn can increase team confidence.
At ZEAL, we measure the effort required to implement stories using the Fibonacci sequence. The lower the effort, the lower the Fibonacci number.
For the Software Residency app, we held story grooming sessions where each team member implementing a specific ticket could cast their vote. This allowed each member to show the amount of effort they estimate per ticket.
The highest number voted became the story’s point, so that those that estimated a story requires high effort could be fairly considered. Any stories pointed at 5 and above were broken down into smaller stories.
It bears to mention that one of the main reasons for pointing is to make sure everyone on the team is on the same page. If someone points a story low and another person points it high, this is a major clue that there is something further to discuss about the story. Only after more conversation can a final number be agreed upon.
Acceptance criteria are the requirements needed to complete a story. It’s part of the “definition of done” and helps implementers with structuring tests.
When writing acceptance criteria, it’s important to not prescribe a way to complete an action (”must have a button at the bottom left that when clicked does x, y, and z”). Rather, acceptance criteria should give developers and designers room to be subject matter experts.
Describe what success looks like—yes—but refrain from being too prescriptive about it. So, instead mentioning button placement, your criteria could instead state, “must have a button that when clicked does x, y, z”.
To stay Agile, it’s critical to keep all of your project communications in one place. For the Software Residency app, we used GitHub Projects to organize our stories, but the software you choose is completely up to the needs of your team. Our clients have used a variety of project management tools like Shortcut, Pivotal Tracker, Jira, and Trello. As you can see, there are quite a few options available!
To help you choose, you should weigh user limits, cost, integrations, and ease of use when selecting your project management software. Ideally, your selection should be a tool you can use to manage your project for many releases to come.
There is quite a bit involved with writing great user stories, but ZEAL’s experts are uniquely positioned to help your team succeed. So don’t go it alone! We’d love to walk you through the fundamentals of great user stories to propel you toward award-winning products. Drop us a line to get started.
Photo by Patrick Tomasso on Unsplash
This article has been written in collaboration with Lisa Panke and Kevin Craine.
Are you ready to build something brilliant? We're ready to help.
.jpeg)
.jpg)
