Originally published in my blog: https://sobolevn.me/2019/02/engineering-guide-to-user-stories
Agile people are obsessed with writing user stories...
For further actions, you may consider blocking this person and/or reporting abuse
Very good article! 🎉
I wonder how you manage really complex situations? Let me try to describe it with a dumb example. Imagine you're writing specs for an app similar to instagram (and with really fine-grained control), and you end up writing a scenario like:
I remember working with scenarios that had like 10 Given statements or so. And I couldn't really see how the number of statements could have been reduced.
You have to apply abstraction to merge several steps together. Or apply decomposition to separate them. Let me explain, please.
For example: you want to be notified when someone posts likes on your posts/images/etc. We all know and love this feeling. For this situation it does not really matter how did you create this content. You only write specs for the reaction part.
This is a first feature: receiving notifications. Disabling the ability to react is a different feature. And should be specified as a different feature. Because notifications only make sense when readers are allowed to posts reactions. However, you can mention that all content for feature
authors are notified about readers' reactions
is allowed to be reacted on. You can useBackground
tag for that: relishapp.com/cucumber/cucumber/do...I hope this helps you.
Thanks for the reply!
Then this implies to me that I might end up writing long
Backgrounds
.Do you maybe know some mature open source projects where they're doing BDD the right way? I would love to analyze something in depth.
Nope, sorry :sad:
I only know the theory, but I think the scenario setup can be abstracted in the direction you talk about it in the office. That is, do you go around saying “let’s make a great notification feature for posts with notifications enabled and permissions are allowed and the user clicks etc etc”? No, you have some shorthand that the organisation accepts (or is ready to adopt). Internal language can have deep meaningful abstractions and that worth capitalising on. The BDD part of Gurkins is to identify those ways of talking.
Well, I think so at any rate. I think your question is really good and gets to the heart of the complexities with full behavioural test coverage.
Great article!
Hypothetical situation, how would you write a new story in a subsequent sprint if you wanted to add
push notifications
to the existing feature?Well, you can copy-paste existing scenarios/features. And edit them to match your new feature.
Or, you can use
Scenario Outline
tag to parametrise your specs. You can use it if features are absolutely similar.Thanks for the response Nikita, however I don't think I was clear enough with my question.
Ignoring any acceptance tests, dealing with just the story:
So this was for using
webhooks
, but coming back for a second sprint to addpush notifications
I'm unsure how the new story would be written, since it doesn't contain any implementation details to differentiate from the original story. What do you think?That's the most important part: your user story does not change. And it should not be duplicated as well.
You can write new
Scenario
s in the same file. You can even use parametrisation to inject dependencies to some of your existingScenario
s. And cover new corner-cases inside newScenario
blocks.Example:
Right got it, thanks for clarifying 👍
Once a user story is done, it should not be back to backlog. If you have some enhancement, create new story.
You can write like this:
Ah, I might misread your scenario. In case that you mentioned about the push notification between GitLab and your system (in additional to webhook), you may create a technical task to address the issue.
rgalen.com/agile-training-news/201...
In the end, technical task should only be considered if it has some business value in it. Try to find some way to describe the value, otherwise, if you want to go fast and the product owner and stackholders understand the value behind the lines, then just use technical task.
This is amazing! The fine-tuning of a very common issue is an awesome example. Showing this to my work colleagues, and I'm going to try and use this technique going forward with whatever work I do. I always find that putting in a little extra effort upfront does wonders for the quality and speed of producing an outcome.
Thanks for the write-up!
P.S.
compliment
->complement
Thanks!
P.S. Fixed.
Great tips. I'm plan to share this with my network.
I wonder if the user story could be improved even more, by splitting on the 'and'? For instance, "So that I can overview and track the issues' progress" becomes, "So that I can overview issues..." and "So that I can track issues"? Maybe I'm not familiar with the term "overview"?
Oh boy! That's a really interesting method, I'll give it a try for sure.
I'm having this trouble, a simple user story that's hard to implement so the estimation is bad and I didn't know how to solve this effectively, I think this method could do the job!
Thanks a ton.
THIS GUY GETS IT.
Thanks for the share, and this nice approach how to link your stories better to your source! ❤️
Bloody awesome! I hope many developers (and BA's) read this. Clear thinking and clear user stories leads to clear and usable software.