It all starts with the user
This is where it all comes together
To understand a product, especially when managing its creation and feature set, you have to identify and empathize with the user. It is why almost all user-facing work for a product starts with the user view. To practice this, technical requirement documents are replaced with user stories. User stories ladder up to an epic and epics ladder up to parts of sprints, sprints or multiple sprints. It is highly recommended to never have a user story span multiple sprints — it usually means that there is too much work buried in the single story. When a user story is created, it is, by essence, the exact “demand” of the user. Although more information, user experience notations, designs, etc can be included in the user story in a ticket system, there is a purposeful lack of detail for the team to build against. This lack of detail is a delicate balance and can be cause for concern across the team but there is a purpose. Traditionally, engineers (either front-end, back-end, full-stack, whatever) were prescribed intricate requirement documents and instructions and they built exactly that. Not only is this not fair to an engineer, it prevented some of the smartest people on a team to think outside of the box, potentially coming up with a better way to implement something or even a simpler way to get it done. The lack of clarity is to allow your engineers the autonomy and freedom to dictate how they want to build something under the common strategy and patterns dictated by their lead.
So, let’s look at a user story in the form of a “card”. I am a huge fan of using Kanban Cards and Boards in software development. I will write more on that later as the process is pretty slick once you understand what makes up all of its parts. The first part, this:
Although this is a bit rough, it’s a simple example of what a user story card should have. The first part of the story itself, written from the perspective of the user on what they “want” to do with the product. In this case, they want to be able to update their profile with a photo / image. The next thing you should notice is the difficulty of the story. This is usually on a scale of 1–5, with 5 being the most difficult and 1 being trivial. You can use any point system you want to signify your story difficulty, just make sure it makes sense to the entire team without a learning curve. [I have seen teams use villains from Marvel Comics, characters from the Hobbit, Star Trek ships, etc — although these can be important parts of a team’s culture, they are not universally known or accepted. If it can be debated, it isn’t an accurate scale.] What this doesn’t show is what is available now, how that should be implemented, or for that matter what it should look like. That level of detail is in the ticket, usually in a system like Jira, where information, files, and other data can be stored and accessed easily.
I purposefully left off anything on this ticket pertaining to a status, as we will get to that on the board discussion, but all user stories always have a status that can range from “Ice Box” (usually meaning it might not be touched for a while, if ever, by the team) to “Released”.
