How to go about a user story?

Neha Saggam
Technogise
Published in
3 min readMar 27, 2019

Recently, I started pair programming with one of my colleagues and learnt a lot of things during those sessions. Through this article, I would like to share few points which might help others as well.

At my organisation (Technogise), we prefer following AGILE practices.

In agile, as you may know, there are Epics / Features broken down into user stories ending up creating a scrum board of stories, which are categorised into Backlog, WIP, Review, QA etc.

Photo by Kelly Sikkema on Unsplash

What is a user story?

According to scrum.org, Qualitative notes, placeholder for one or more “conversations” written in the end user perspective, which are held in order to satisfy the requirement.

Lets go with an example,

User story: When logged in as an admin/super-admin, user should be able to grant/revoke access of a normal user.

Every user story should be divided into scenarios.

What the heck is a scenario?

Think of a scenario as a test-case for your user story, you write a scenario, you validate it by asking questions, then you refactor it by applying the answers to it.

We now divide the above story into following scenarios,

  • An admin can grant access
  • An admin can revoke access
  • A super-admin can grant access
  • A super-admin can revoke access

Scenarios should be independent as far as possible. Allowing you to write test cases against them, implement the functionality, commit and then push change set after every use-case completion. This results in smaller yet deliverable commits which make rollbacks easier in case required.

As per the above example, if you complete #1 scenario you can commit and send it for code review, by the time it is reviewed you are ready with another commit. Yay!!!

Always remember, Commits should be frequent, small and atomic.

A common Agile philosophy, is along the lines of,

“If you can’t commit before going home, revert”.

Now that I have the scenarios ready, I would start implementation. But wait I have some queries,

  • If we revoke the access, how do we handle the existing references? Delete them or flag them??
  • How do we grant access to the user? By sending an invite or from the list of people already added to our organisation ??
  • Should we be sending confirmation email or just a notification saying you have been granted access ?
  • What type of access can we grant ? Admin or Super-admin ?
  • Can an admin give super-admin’s access ?

As we started our `Thinking Toolbox`, we ended up from few queries to a lot of queries 😜, that too before our implementation.

So, No going to and fro, deleting and re-writing the code again and again, because hey! we have brainstormed and have our queries resolved.

Collaborate, Converse and then Conclude.

Now, once you have a clear picture and you get a go ahead, START CODING!

Red -> Green -> Refactor -> Commit

Drawing by Me

Why is it important to follow the above approach, because you,

Think -> Analyse -> Anticipate hurdles -> Gain big picture

  • You start questioning
  • Find out the missing business rules if any, before hand.
People are too Focused on the Runners, not the Baton. That is, everyone is busy but not necessarily progressing work items.

You might find this time consuming initially (even I did 😖) but trust me you will end up saving a lot of re-think, re-implementation, gain confidence, providing timely deliveries and de-risking yourself 😎.

Now you have everything in place so what are you waiting for ! Start Coding!

Photo by William Stitt on Unsplash

Thanks to Dattatray Kale :)

Please help me improving my writing by giving feedback.

References:

[1] https://martinfowler.com/articles/itsNotJustStandingUp.html

[2] https://stackoverflow.com/questions/1286057/continuous-builds-and-agile-vs-commit-often/1286069

--

--

Neha Saggam
Technogise

An application developer, a nature lover and an imaginary traveller.