Managing blockchain projects with user stories
Part III — Managing user stories
This is the final of a three-part blog describing a way of applying the agile methodology for blockchain projects. In this part, I’ll discuss a technique for managing the process of refining user stories to avoid the analysis-paralysis syndrome (i.e. too much focus on writing and refining user stories not starting the project).
Unless you are planning to build a product that only says “hello world”, you will have to write more than one user stories. It is also unlikely you will ever get your user stories correct the first time.
User stories need to be refined as the project progresses and adapt as circumstances changes. The question is how do we go about refining our user stories without being trapped in an endless cycle of stories refinement not doing the work?
To answer that question, let’s revisit the agile development lifecycle process. There are, in broad terms, two types:
- Kanban process
- Scrum process
I am going to assume for current discussion that these are the only two forms and proceed to recommend ways of stories refine based these forms. In reality, you will find many projects adopting a combination of these form of agile process. Use the recommendation here to adapt according to your process.
Kanban
This is typically described as a “pull” system for managing work, by extension, user stories. At the heart of the Kanban process (i.e. a way of working) is the Kanban board (i.e. a visual aid that is also often used in the Scrum process). Figure 1 shows a simplified Kanban board.
The Kanban process is based on one backlog (or “product backlog”) of user stories, stories at the top of the backlog are considered highest priorities and the team will start work to fulfil the top story (or stories if you have the capacity to work in parallel).
Kanban teams could also use swimlanes to represents Epics and stories within each Epic.
The Kanban process does not prescribe any specific ritual like you would find in the Scrum process. Assuming that you are starting a new project, the first step is to populate the Kanban board. This would be referred to as project inception or, in Scrum speak, sprint zero but there is no sprint backlog in the Kanban process. Project inception would be the only time you would start populating the backlog at mass. Thereafter, you will simply populate the backlog when needed.
Start with establishing swimlanes to represent epics. Refine the epics by writing user stories and populating the backlog. At this juncture, include user stories. Avoid appending stories with acceptance criteria or any detail description. Just focus on writing “As…, I would…, so…”
In a slight departure to traditional Kanban process, I recommend the creation of a column called Icebox. This is to hold stories that you think might be useful and you would like to keep in view.
For example, in Part II of this blog, I created, in my hypothetical scenario, two user stories (see Figure 2 and Figure 3) as a refinement to the epic related to user registration. Both were fulfiling the process of registering the persona Paul but they represented different ways of achieving the same goal.
Due to time-budget constraint, you have decided to go work on story represented in Figure 3 but you feel that Figure 2 could be revisited if time-budget permits. In this case, simply “icebox” the story described in Figure 2.
Once you start working to fulfil the requirement of the user story, you start refining the user story. You can either split the story into smaller stories or add an addendum to it to clarify. For example, in your doing column, you could add a sub-column call “refine story”.
Unlike the Scrum process, there is no fix time bucket like a sprint backlog to deliver a feature or an epic. You deliver when you are ready and each user story should be something that is of value to the user.
Because you are delivering stories when needed, it means you can at any point elect to change course. You may decide to switch stories mid-flight in your development process for example switch from Figure 3 to the one in Figure 2 (i.e. icebox 2 and de-icebox 3). There are consequences for such action in terms of time and budget but this approach means change impact a user story, not an entire sprint.
Scrum
The scrum process is basically a “batch” process where you have a “product” backlog (same as in Kanban but you work directly from there), and a “sprint” backlog. You batch a set of user stories into the sprint backlog and pick work (user story) from there. There is also a set of ritual that is “prescribe” in the process and this is illustrated in Figure 4.
If you are following the Scrum process, I would recommend your “product backlog” contains stories in epic forms. You could then split your “sprint backlogs” as representing epics of user stories. Each sprint backlog equals to one epic, for example.
At the start of each sprint (i.e. in your sprint planning) refine each epic into user stories. Stories in each sprint backlog should contain the narrative “As …, I would …., so …”, and acceptance criteria, and/or other descriptive formats to add details to the story.
I want to add that this is my recommendation but in the interest of transparency, my preference is for the Kanban process. I expect some practitioner of the Scrum process may not agree with this recommendation.
The key point I am conveying is that when it comes to story refinement, find a point in your process to do it that will not lead to endless story refinement that impedes your ability to deliver.
To me sprint planning seemed like a logical time to do refinement and to avoid trying to “boil the ocean approach” of refining every epic in the “product backlog”, it seemed logical to only do for a “sprint backlog” worth of stories.
The choice of tools to manage your user stories is also critical to the success of using user stories as the basis for managing projects (blockchain-based or otherwise). Some prefer the use of traditional post-it notes on physical walls. Others prefer to use electronic boards (such as JIRA, Pivotal Tracker[1]) with a combination of chat and other social media to exchange information or add to user stories.
Whichever system you choose, my recommendation is for a system where it can facilitate easy story refinement as per described in this blog.
To conclude this three-part blog, I have focused on discussing the user story aspects of the agile process and in particular with an emphasis on blockchain-based projects.
In Part I of this blog I recommend the use of personas instead of user-roles as the focus of user stories. Using personas help disambiguate user requirements more accurately.
In Part II of this blog, I recommend the approached described by Roman Pichler (“10 tips for writing good user stories” and “From personas to user stories”) as a technique for writing good user stories. I also use two blockchain -based scenarios demonstrate the fact the user stories can be used for a technology that is primarily backend based.
In Part III, I have recommended ways of managing stories in the context of the Kanban and Scrum process.
Go forth and start creating user stories for your blockchain-based project!
Note:
[1] In the interest of transparency, I find this agile management tool from Pivotal very intuitive. Some of my recommendations in this blog may have been influenced by it.
