INVEST in User Stories for the Mentoring Industry

Storytelling is a useful skill in any discipline. It serves as a universal language allowing communication across disciplines.

When I was an accountant, I had to write a report that read like a story that would incentivise business executives to change their behavior. The story would get people’s attention, and quantitative data was there to make the story credible.

When I was a software developer, I discovered that the hardest part of building software isn’t writing code, as many people are lead to believe. It’s deciding what to build so that you’re able to give what your customers really want. That’s where it gets interesting, because customers don’t always say what they really want. Or worse, they change their mind, and you waste valuable time building something that’s worthless tomorrow. How do you ensure that product requirements are interpreted the same way by both developers and customers? By communicating requirements in the form of a story.

So what makes a good story? There’s an acronym that software developers use to remind themselves. It’s called INVEST, which was published in a 2003 blog post by Bill Wake.

INVEST can also be used for solving problems in general. Let’s use a hypothetical example where we’re managing a membership organisation (or mentoring organisation). Interviews with several members reveal a disturbing trend.

One of the member’s explanation was, “I don’t read 90% of the emails from the organisation because they get buried in my inbox. I also don’t email anyone else in the program for advice because I don’t have their contact details, I don’t have time to write emails, and other members don’t expect an email that’s unsolicited. We should use Slack, which is the communications platform that I use at my workplace. It’s much better than email.”

We can use this explanation as the initial version of the story.


Is the story dependent on another story being implemented? Or can the story be implemented on its own? The only dependency is that Slack requires Internet access, and since everyone does these days, this story can be independently implemented.


Is the story high level enough that we have room to negotiate the details of how the solution will be implemented? Probably not.

Slack is a detail we should leave out. A story tells you what you need and why you need it, not how you’ll deliver on that need. The how, might not be Slack. It might be Skype, or Facebook Groups, or something that doesn’t exist yet and needs to be created.

Or maybe we’re simply using email wrong and we should set up different mailing lists, like where you sign up for upcoming events, where members email their suggestions to make the program better without being seen as a trouble maker, and where you can ask for advice, and all mentors will get that email and one of them will reply, where you announce to the entire organisation, and where you have conversations about a specific project.


Is it valuable to members to have the story implemented? If it saves members time having to find emails, reading uncategorised emails that are irrelevant, writing long emails to avoid misunderstandings, and phone tagging another member. If it helps us plan and work together to improve the quality of the mentoring program. Then it’s probably valuable, even though we might not agree it’s the most valuable out of all the stories.


Can we estimate how long it would take to implement the communications platform? If we can’t, then we don’t understand the story well enough. It’s difficult to estimate how long it would take to implement a “communications platform that’s better than email.”

A better story that’s easier to estimate could be: “I want a communications platform that automatically categorises messages from my mentoring program, alerts me to important messages that need me to reply, shows me a list of members who I can call and get my question answered, and I don’t need to explain why I’m contacting a member because my message has already been categorised.”

In this case, we’ve clearly defined the features, and we can use our experience to estimate how long it would take build the categorisation feature, an alert feature, a mentor availability feature and so on.


Is the story small enough that it can be done within a few days, if not hours?

What’s an example of a big story? It’s wanting an all-in-one mentoring program management solution that automatically reminds subscribers of upcoming events, tracks progress of members, schedules tasks for members to complete, collects membership subscriptions, and is also a communications platform. The problem with such a big story is that it’s going to take weeks or months to do. And when it’s done, there’s a greater chance that it’s not what your customer wants.

When you have small stories, such as a communications platform that can be implemented within days, you get customer feedback sooner, which you can use for your next story, and the next. You’re continually kept in sync with the customer, which avoids nasty surprises.


Finally, if the story satisfies the criteria above, it should already be testable. We should know whether we’ve successfully implemented the story. If we don’t, then we probably don’t understand the story well enough and it’s likely that one of the above criteria is not satisfied either.


Leave a Comment