User Stories: not only for Developers!
July 25, 2022 —Daily, I hear developers say “my1 user story is finished”. And, almost always, they utter this sentence when they have deployed a feature to production2.
But I don’t think a User Story should be considered as “done” at that time!
On a software development project, User Stories should concern more than just the developers. Once written, a US should go from service to service!
Of course, developers rely on them to understand the functionality3 they’ll implement, to understand the user’s need. The US illustrates use cases, which they also may translate into test cases.
But then, once a feature is developed, the US should be used by their QA colleagues4, whose job is to validate it, to make sure that what’s been implemented corresponds to the users’ needs—which are described in the US.
After that, the US should go to the sales department. Yes, the sales people will use the US, which describes a need and the feature implemented to answer it, to sell this new feature to their customers or prospects!
After that, the training department should use the US to update its teaching materials. Same thing: it describes the needs of the users and how the application meets them.
And, finally, the US should be transmitted to the support department, so its employees know what functionality has just been deployed, how it’s supposed to work. This way, they will recognize if customers calling support are misusing the feature5 or if they have identified a bug!
By the way, I didn’t note it above, but US doesn’t magically appear in developers’ sprints.
It starts its life much earlier, when a need is identified—by a product owner or through another department, like training, sales or support!
After that, it may go through a design phase, which may include usability and visual elements, maybe handled by other teams…
Also, in the case of a complex business need, the US will likely pass through the hands of business experts before reaching the development stage!
So, to meet a user’s need, how many teams work with the same user story?
At least seven, in the situation I described above?
Identification of a need (business, training, support, sales), business specification, design (usability, graphics), development, QA, sales, training, support…
In a software cycle, the development team represents only a small part of the life of a user story—and I don’t see how it can, on its own, declare “we have finished a User Story”!
Many times, I’ve seen several teams working on the same feature and creating a different User Story for each team! Even though they were aiming to meet the same user’s need!
For example, I’ve seen a User Story for the business experts who were tasked to specify the User Story for the developers, followed by another User Story to create an A/B test for the production launch… Then, yet another User Story to monitor the results of said A/B test two weeks later… But… No! This is madness! None of these pretended User Stories are User-oriented!
Some split between teams6, even if I don’t always like this approach, well, maybe… A technical breakdown, likewise, why not.
But let’s not call these items, these subdivisions, User Stories! Tasks, maybe?
Let’s stop lying to ourselves and pretend that one single part of the work meets the user’s need, when it’s the whole process that leads to a solution that meets the users’ expectations!
I know some of you will ask about those, so here it is: yes, there are some stories that only concern the development team.
For example: reworks, adding or fixing tests, switching CI/CD toolchain, updating a framework, applying security patches, and many others.
Just don’t go around calling those “user stories” when they aren’t related to users at all.
Be honest, and call them what they are: technical stories, technical tasks.
I’ve even seen, many times, people from support or sales departments go see developers and ask “does feature X exist in our software?”, “what does feature Y do?” or “how is feature Z configured?”…
Well, every time, I thought something was missing.
Communication, no doubt. And documentation. Including documentation for and in the sales’ teams.
But most importantly, each time, the feature in question had been implemented without its User Story navigating to the colleagues in charge of selling it!
This is incredible! How can this even work?
Well, it doesn’t!
Illustration by Will H McMahan on Unsplash
-
By the way, I think a developer who says “my user story” is mistaken and hasn’t understood his/her role. A development task, entered in a team’s sprint, shouldn’t be the responsibility of one person, but of the entire team: the team commits to a task, not the individual. So one shouldn’t say “I finished my user story”, but “we finished our user story”. ↩︎
-
That is, in companies where developers are responsible for pushing features to production. If your developers are only responsible for committing code and another team is deploying it (which is sad), coders will say “my US is done” even sooner, long before anything has reached users! ↩︎
-
Yes, developers should understand the users’ needs. Their role shouldn’t stop at “code what I’m told”. ↩︎
-
A QA team? Well, yes! If the only people who test are the developers, they won’t find many bugs: the cases they’ll think to test are those they thought to implement! On the other hand, a new person will have new ideas of things that can break ;-). Lacking a QA team, I’ve seen development teams where, on major stories, developers who hadn’t worked on a US would do a test pass—and they’d always find flaws in their colleagues’ reasoning ;-) ↩︎
-
If customers call support because they’re misusing a feature, this is probably an opportunity for the support department to take notes and suggest an evolution. It’ll make the feature more intuitive and make life easier for their users (and to have them call support less often). ↩︎
-
Breaking things down into distinct tasks that are assigned to teams introduces dependencies and leads to features that take months to be delivered to users and to bring value to the company. This is because splitting work between distinct teams require coordination (which is hard), and teams are always busy with other things. Maybe it’s time to consider creating feature teams, where one team is responsible for one feature? 🤔 ↩︎
