User story: Informal description of a feature of a software system

User story

In agile, a user story is a functional increment of the software, agreed with the customer or with the product owner. Each user story must contribute adding value to the product. When writing a user story we must specify for who is made, what is done, and why it is done, explaining the business value added. Defining good user stories affects directly to every stage of the story lifecycle that we are going to visit after.

There is an assessment you can perform to your user stories to evaluate how good they are, it is called INVEST:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

After having defined good user stories, let’s see how we can improve the whole story life cycle in order to improve the velocity of our development team. The next schema, it is a generalistic schema, the story life cycle may be slightly different from one company to another and have much more steps maybe, but the core concept will be very similar:

lifecycle

Idea: Everybody should be able to contribute here. As a software business, we need disruptive, inventive and creative ideas. We should not only restrict that crucial part only to certain roles or members of our team. An idea should be able to come from any mind, for instance, a developer could provide a competitive differentiation taking advantage of the technology, or a sales person could identify and tackle new requirements based on the contacts with the clients. The product needs the contribution of every member of the team.

Issue: We don’t want these ideas to get lost, so we write them all down here. In all stories identify, for who, the what and the why is important so we don’t forget why we wrote that after some time. Afterwards, it’s the PO’s duty to arrange the prioritization of these stories, or even remove them when they are not needed.

Plan: This phase does not only refer to deciding when we implement the story, it also refers to deciding what we build. Here is when this negotiation between the business and development takes place. Developers should make sure they deliver exactly what is needed and nothing more than that–don’t develop things that weren’t asked–.

Code: It is the core of everything, here it is when we build what is needed. Even though I call this stage as code, I mean a bit more than just the word code. Design goes here, documenting these design decisions goes here, writing tests also, if they are written before the code, even better(TDD). Refactoring when possible, before and after writing the code… This is the phase when developers apply all their technical knowledge.

Commit: Commit is here to remember you to use a code source control. Luckily, it is not that necessary to remember that in 2020, but just in case. Commit often and commit while you are writing the code, do not wait until the end and do 1 big commit with everything.

CI: Continuous Integration it is a powerful tool that gives feedback to the developer about the code they just wrote. The code of each developer is automatically evaluated here together with the whole system in a production like environment, so we can make sure that the changes introduced won’t break anything unexpectedly.

Review: This is the phase when developers give feedback to each other about the code produced. It is also a way of spreading the knowledge between the team on the job done. Pair programming could help to reduce the amount of rework required in code reviews, because the feedback is immediately given while writing the code, we don’t need to wait until we finish the whole task to get feedback about it.

Merge: In this point, the enfasis goes to the branching control (git flow). It will determine the next phase. We have to take advantage of a tool like git. (avoid svn, mercurial,…)

CD: The continuous delivery / deployment, it is the ability to put every user story into production in just a few minutes. The difference between continuous delivery and continuous deployment is a business decision, the business decides which stories go straight to production and which ones don’t, but all the stories should be able to go into production on their own.

Production: Notice, I went straight into production. There may be other environments for testing purposes or other teams, but I keep them out of this process. For the vast majority of failures in most of the companies, it is cheaper to recover from failures than trying to prevent them. Meaning that, if we have a reliable test base, it is more efficient to accept that we may introduce a minor bug into production, than have an entire team manually testing (preventing) a bug to go into production, because even then, you cannot guarantee that you won’t sneak any failures anyway. Again, in most of the business, not all.

Monitor / Evaluate: Monitor everything we do is crucial to understand what is going on in our systems in order to make improvements later. Here is when we can evaluate the story delivered.

Feedback: We have to check what we did, to make sure that it fits the needs of the clients. Otherwise, why did we build that at all? Why have we built that in this specific way and not a different one? If we don’t gather feedback after each iteration we are failing at the most elemental concept of agile. We also have to reduce the fear to experimenting and try new and creative ideas, if they don’t work, nothing happens. But these are the things that may make the difference for our business.

The speed we gain completing the circle(lead time) is the speed we can provide to the business. This speed is not only in terms of moving forward, it also means speed to change the product fast. Business should be able to steer in order to find the perfect market fit, and we, as developers, have to provide them this ability to adapt quickly, in other words, we as developers have to be agile to let the business be agile.


Thank you for reading all the way until here! If you want to comment this post you can do it on medium.com or dev.to.