In the previous article we defined what we are going to build, a CLI client for Microsoft ToDo powered by MicrosoftGraph. In this article we break down the application into user stories.
A user story describes how a user accomplishes a valuable outcome — something they care about. They have the format “As a role, I need to do an activity, so that I can get a valuable outcome.” A sample user story for a blogging app will be something like, As a publisher, I need to review and approve articles so that they can be read by our subscribers. The valuable outcome is subscribers reading the article.
In an agile set up, user stories are the unit of work. Fulfilling a user story involves doing the necessary work — ie writing backend and frontend code — to have a working product when you’re done. I prefer this to working on an app for months and not have anything to show for it.
It is common for feature requests to be presented as user stories, this is wrong. A feature request to add Oauth2 authorization is not a user story because it does not capture the value to the user. Users careless about your authorization strategy, they just want to get something done.
For the first iteration of the CLI, we are going to keep it simple and have only two user stories.
- As a task owner, I need to create tasks so that I can track what I need to do.
- As a task owner, I need to view tasks so that I can see what I need to do for the day.
In the next article, we design the architecture for the CLI client.
Building a Product From Scratch: Problem Definition
In the previous article we defined what we are going to build, a CLI client for...