Besides being at the top level and displayed on a kanban board, the tasks can also be contained by another type of work item: the User stories. A user story is a work item similar to a task, that can also be added to boards, has a similar workflow and most of the same data. However, instead of being a specific piece of work to do, user stories are higher level features to implement, a requirement to be added to your game from the point of view of what adds to the player experience, which can also contain other full tasks inside. This adds another layer of organization between the tasks and the design of your game. This way, you can create general features and put them in the backlog or boards for simplified management, so you can move and organize the story and all the smaller tasks inside all at once.
If you are familiar with the Scrum methodology, you already know what a user story is, but if you are not, I recommend you to read more about it here. No matter if you are not using Scrum or another agile methodology; the user stories as an item that can contain children tasks, is a great way of improving the organization and manageability of your work in HacknPlan.
The lifecycle of a user story it’s basically the same than a task has:
- Backlog: The backlog is a container for future work, and you can place your user stories there to be polished, detailed and ready to be added to a sprint.
- Planned: In HacknPlan, you can create kanban boards with deadlines as a way of creating sprints or iterations. When a user story is ready and added to a sprint, it will be placed on the Planned column of the board, waiting to be started.
- In progress: This means someone already started working on the user story. User stories can contain other tasks inside, which have their own internal stages.
- Testing: When a user story is finished and needs to be evaluated, it can be placed in the testing stage to validate it meets the expectations.
- Completed: When the user story is validated, it can be set as completed, which will close it.
Besides the stage, during the lifetime of a user story, it can be assigned to one or several team members. Additionally, the tasks contained in the user story can be assigned to individual team members. When a member is added to a task that belongs to a story and the member is not assigned to the story, it will be assigned automatically. On the other hand, if a member is removed from a user story, it will also be removed from all the child tasks they were part of.
Classification of user stories
User stories can be classified by different aspects that allow to organize them properly and help you better manage them:
- Game design element: The game design model allows you to create a dynamic structure of concepts in order to have documents and tasks under the same organization, so by setting a game design element to a user story you are giving context about the topic, feature or concept this user story relates to from a higher level, like an epic. This field is optional and, but it is recommended to have your user story under the game design model for a better organization.
- Board: As we mentioned during the lifecycle explanation, a user story can belong to a board or not (which means it’s in the backlog then). A board is nothing but a way to classify user stories and tasks by some criteria, which normally is a sprint or iteration of your development cycle.
- Tag: You can assign custom tags to your user stories to give them extra meaning or a special condition. For example, you can add a tag that says Impediment in red color so you can see that something is going on just with taking a brief look at the card.
Creating a user story
Now that you know more about user stories, let’s create one. In order to do that, click on the Create entry on the left menu or press U on your keyboard. You also have other shortcuts in important places, like the Kanban board or the design element editor. This opens up a user story creation dialog.
The user story creation in HacknPlan is progressive, meaning there are many possible fields and information to add to a user story, but it’s initially hidden not to overwhelm you and keep it simple. If you need to enter more data, you can click on the Fields button and enable (or disable) the fields you want. If there are fields you always need, you can check the Remember fields option, which will save your field configuration as the default for future user story creation. Additionally, administrators can visit the section Administration -> Modules, where they can set some fields of the work item creation to be mandatory.
The list of fields that can be added to a user story is:
- Project: You can create user stories from anywhere in the application, so you need to select which project the user story will be added to. It defaults to the currently open project if any.
- Title: The title of the user story.
- Design element: The game design model element the user story belongs to. It defaults to none, unless you are in the game design model page and selecting a specific element, then it will default to that one.
- Board: The board the user story belongs to. If you are creating the user story from a specific board the default value will be set to that one, if not it will be set to the default board (which you can set from Administration -> Boards & milestones), and if no one is set it will be set to none (which means the user story goes to the backlog). You can also alter how this automatic board detection works from your user Settings -> Application, Behavior panel.
- Description: Add a complete description, links, pictures, and everything that is necessary to clarify what the functional requirements and expectations of the user story are. This field supports markdown syntax, so you can format the text as you wish.
- Estimated cost: This value measures the effort you estimate will dedicate to finish this user story. It will be time or points depending on what you configured for your project. Defaults to zero.
- Importance level: It says how important the user story is. It defaults to “normal”, which does not create any visual sign on cards.
- Due date: Although user stories are normally done within the scope of an iteration or sprint, they can also have their own due date. It defaults to none.
- Tags: You can add one or more tags to your user story to add extra information or categorization that will be visible on the card. You can enforce the creation of at least one tag from the Administration -> Modules section.
- Assigned users: You can add one or more users as assignees. You can enforce the assignation of at least one user from the Administration -> Modules section.
- Tasks: You can create child tasks directly from the user story creation editor. Since story tasks belong to the user story, they don’t have the typical classification fields, like board, design element…
- Attachments: You can attach files to the story from your computer or Google Drive, that you can also reference from the story description. Additionally, you can drag and drop the files into the user story creation dialog, which will upload them automatically.
- Dependencies: The dependencies are work items (user stories or tasks) which block the user story until they are completed, as a way of visually detecting bottlenecks and making the prioritization of items easier.