April 11th, 2024, posted in learning
by Adelina
This is the last article in a three-part series called “A design-first approach to writing great user stories”. In this series, we talk about why we need to approach product discovery in a more visual way and how to do that in order to write better, more useful user stories. Check out the rest of the articles in the series here:
Intro: A design-first approach to writing great user stories
Part 1: How to use UI/UX design as a tool to discuss, clarify and agree on app requirements
Part 2: Turning your UI/UX designs into user stories
If you want to read more on our development process as a whole and how we help businesses go from idea to app, also check out our MVP series.
Half of the work of providing good estimates is writing good user stories. As we`ve seen in the previous article, there are several core principles you can follow when writing user stories. Making your user stories independent of each other, small in scope and testable are just a few of the things which will help you estimate the development effort more accurately.
Once we have the user stories written down, we start by scheduling a meeting with the team. Unlike most meetings of this kind, we like to involve people across different areas. In addition to the Product Owner and/or Project Manager, Developers and Technical Lead, we also bring in the UI/UX Designers, who walk the team through the screens in parallel with the user stories. When estimating the work, we want to make sure we take into account all three perspectives:
- the project management perspective
- the development perspective
- the UI/UX perspective
How we estimate user stories
To estimate the user stories, we rely on the same template we use for writing them. This helps keep everything in one place, including comments, screenshots and links to designs the user stories are referring to. After the meeting, this document will serve as the go-to file for everything related to the project. Think of it as the starting point for a central knowledge base, which will then be transferred into a project management tool, such as Jira or ClickUp, as more things are added and tasks are created.
When estimating user stories, we generally stick to the following three practices.
We use hours instead of story points
We generally estimate the user stories in hours, as opposed to story points. If you`re not familiar with story points, they are units of measure for estimating development effort independent of time. Instead of months, weeks or hours, the team assigns story points relative to work complexity, the amount of work and the level of uncertainty or risk. This will generate a scale, where, let's say, 20 points is the upper limit, for particularly complex, lengthy or high-uncertainty user stories, and 2-3 points are assigned to easy, straightforward and low-uncertainty tasks.
Despite their popularity, story points do have some significant drawbacks. In fact, some companies are beginning to move away from them, for some of these reasons.
❌ Story points will eventually need to be converted into time, which leaves you right where you started.
❌ Story points cannot be converted into time until you actually implement something or have enough data to back you up. A common practice for turning story points into hours is to see how many story points you can finish in a 2-week sprint (also known as velocity) and then calculate from there.
❌ Hours are a familiar concept, story points can be confusing, especially to anyone new to the team. Plus, if the team changes, you might need to recalculate the scale based on skill level. This is true for hours as well but, being less granular, you can always estimate with a qualified person in mind.
While there is no magic formula for estimating development time, we found using hours instead of story points is just as accurate if not more. And with less intermediary steps.
We keep frontend and backend estimates separate
We use separate entries for frontend and backend estimates. Counterintuitive as this might seem, this actually gives us a more accurate overview of the work to be done. Why? Because rather than asking someone to estimate the complete effort it will take the team to get the story done (which implicitly means estimating other people's work), we let frontend and backend devs estimate their own part and then we put everything together.
We think in min-max terms
One of the problems with both story points and working hours is that they tend to use a single value: task X takes 11 story points or 9 hours to get done. This doesn't leave a lot of wriggle room and it doesn't account for real-life disturbances and “time eaters”.
So, instead of using a single value, we always provide a minimum estimate and a maximum estimate for each user story. The minimum value represents the time needed to complete a task if everything goes smoothly and nothing unplanned happens. The maximum value accounts for any technical difficulties, hidden complexity or unplanned issues.
Once we decide on a minimum estimate, we increment by a fixed value, for example 2 hours, to reach a maximum estimate: 2 hours, 4 hours, 6 hours etc. Having a fixed value to increment by keeps the differences between min-max estimates meaningful. Completing a task in 2 hours and 15 minutes compared to 2 hours is not a significant difference to base your maximum estimate on. Having a fixed value to increment by can also tell you if your user stories are too big. If you find yourself incrementing a single story beyond a certain threshold, you might need to go back and break that story down into smaller parts.
We also found that, during meetings, it's easier for two people to agree on a minimum and maximum value, as opposed to a single value. People tend to overthink fixed estimates and second guess their decision a lot.
The meeting
Traditionally, planning poker uses story points to evaluate development effort. We`ve adapted poker estimates to use working hours and we rely on this method in all our planning meetings to estimate the required person-hours and overall time.
Our meetings usually begin with the Product Owner and/or Project Manager explaining each story to the development team, while the UI/UX Designers accompany them in presenting the designed screens. In turn, the development team discusses the work involved in implementing the stories, until they believe they have enough information to accurately estimate the effort.
At this point, each team member independently estimates the effort, assessing backend and frontend work separately, with minimum and maximum work hour estimates for each story. Let's say there are two front-end developers in the team and three back-end developers. A story will have two minimum estimates and two maximum estimates for frontend work, as well as three minimum estimates and three maximum estimates for backend work.
Once everyone puts down their estimates, we simultaneously reveal the estimates for each story. If there are huge discrepancies between team members, we discuss them and the reasoning which led each person to that estimate. Discussion rounds continue until everyone is ready to vote and reach a consensus on the effort needed for the frontend and backend implementation of the stories.
Occasionally, a consensus might be hard to reach for a particular story. For us, this is a sign that the story might not be properly explained or structured, so we use this opportunity to improve it. In addition to their main goal of providing estimates, meetings of this kind are a great feedback tool. They are a good opportunity to see the user stories in action, long before they are experienced as an actual app by the end users.
This concludes our series on how to write great user stories and everything in-between. Drop us a line if you found the articles in this series helpful, or if you want to actually apply them in your work.
