When developing a software with agile practices, you describe expected features through « user stories », like « as <the primer owner of the smartphone>, I <swipe the lock screen> to <unlock the phone> ». During the project, you use a shorter version : « swipe lock screen ».
I see on a regular basis some product owners (the people with the role of writing user stories) prefixing the action with auxiliary verbs like « As a customer, I should be able to buy an item » or “I can buy an item”. Well, it’s not a User Story anymore. A User Story has to use an action verb in first person, and nothing more.
When you use “should be able to”, you miss some important benefits that are at the core of agile approach. Using a real action verb along with the first person while writing has you picturing a concrete scene in your mind. You get under the user skin, as anyone will when reading your work afterward.
First, you get a better reality check. You see details you would have otherwise missed, the gesture that doesn’t work, the layout that seems odd after all.
Then, you’re thinking with the user interests in mind, not the easiness to code or your own willingness to show that top-notch geeky feature you so much wanted to implement once in your life.
So, at a glance : don’t use these auxiliary verbs, “should be able to” or “can”.
A bit of clarification : some modern automated tests use « to shall » in their descriptions. Example : it should unlock when a user swipe the lock screen. There’s even a test framework called « shoulda ». In these tests, the subject of the sentence is the softtware, not the user (You program the software, it should do as you expect). The purpose is to wrap all test titles in some automated test coverage reports :
the software should do X : Check
the software should do Y : Check
the software should do Z : Failed
So figure precisely which one you’re writing and if it’s a user story, be the user and describe what you are actually doing.