Anatomy of a task

 

The task is the main entity of the HacknPlan system. It represents a small and specific unit of work, and it can be classified by different aspects or characteristics relative to your project organization.

The lifecycle

The lifecycle of a task goes from the moment it is created until the completion (or deletion) of the task. During its lifetime, a task can go through several different stages:

  • Backlog: The backlog is a container for future work. Many times you create a task but you don’t know when you’ll work on it, so it’s added to the backlog. It’s possible to add tasks directly to milestones too.
  • Planned: HacknPlan is designed for iterative development, so when a task is ready to be started it should be assigned to a milestone. This puts the task in the Planned stage, meaning that it will be accomplished during a specific milestone but it hasn’t been started yet.
  • In progress: This means someone already started working on the task.
  • Testing: Most of the times, a task is somehow evaluated after is theoretically finished, in order to verify that it fulfilled its purpose. This stage is for that matter, and the testing will vary a lot depending on the type of task: testing some feature in the game, evaluating a concept art, a music track, checking a model works properly in the engine… It’s quite common a task moves among In progress and Testing stages several times, as part of a process of correction and re-evaluation.
  • Completed: When the task has been done and verified, it goes to the completed stage. The task keeps assigned to the milestone after is completed, this way you can go back to finished milestones if you want to check something from the past. A task can be reopened at any moment.

If a task is moved to another milestone the status of the task will be “reset”, meaning it will go back to the Planned stage.

Besides the stage, during the lifetime of a task, it can be assigned to one or several team members. This assignation is a bit open to interpretation, meaning it would represent a different thing depending on your work style. While many producers like to assign tasks to users right from the beginning (so the user-task relation means duty) and keep the assignation during the whole lifecycle, other people have a more agile approach, where the assignation means the user is currently working on the task, so users are assigned (and many times self-assigned) and unassigned during the life of the task.

Classification of tasks

As we said previously, tasks can be classified by different aspects that allow to organize them properly and help you better manage them. Some of these characteristics are mandatory, which gives you a very reliable and strong structure, and some of them are optional, giving you more flexibility:

  • Category & subcategory: You can classify your tasks depending on the discipline they belong to, like “Programming”, “Art”, “Sound”, “Marketing”… The category is a mandatory field that reflects this classification, which is used to split the kanban board into different role-based boards, extract metrics about them so you know how much you work on each discipline, and also to apply permissions based on those roles. The subcategory is a child field of the category that gives more context and detail about the task within the category, like “3d model” or “2d sprite” under “Art” category.
  • 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 setting a game design element to a task you are giving context about the topic, feature or concept this task relates to from a functional point of view. This field is optional and, although is recommended to have your tasks under the game design model, you can have tasks without one for things like reminders, non-development related tasks, etc.
  • Milestone: As we mentioned during the lifecycle explanation, a task can belong to a milestone or not (which means it’s in the backlog then). A Milestone is nothing but a way to classify tasks by their date of achievement, not individually in this case, but as part of a phase or iteration within your project.
  • Platform: When you are working on a multiplatform game, it’s quite normal most of your tasks are common to all platforms, thanks to the great multi-platform engines we have today. However, there are always some tasks to be done for specific platforms to improve compatibility, performance, or solve some issues. This field allows you to classify the task by these platforms to give them context and also to be able to extract figures from it. It’s also optional, and most of the times it will be empty.

Creating a task

Now that you know more about tasks, let’s create one. In order to do that, press the “Task” button on the header of the page or press “T” on your keyboard. This opens up a task creation dialog with the following fields:

  • Project (required): You can create tasks from anywhere in the application, so you need to select which project the task will be added to. It defaults to the currently open project if any.
  • Importance (required): It says how important the task is, which is especially useful for bugs or support tasks. It defaults to “normal”.
  • Estimated cost (required): This value measures the effort you estimate will dedicate to finish this task. It will be time or points depending on what you configured for your project. Defaults to zero.
  • Title (required): The title of the task.
  • Assigned user: The user who will be assigned to the task initially. It can be assigned to no one. Defaults to the user creating the task.
  • Category and subcategory (required): The category and subcategory the task belongs to. If you are currently in a specific category board panel, that category will be set as default. If not, it will be set to the last used one, so you can save time when you have to create several tasks of the same type.
  • Milestone: The milestone the task belongs to. If you are in a specific milestone the default value will be set to that one, if not it will be set to the active milestone, and if no one is set it will be set to none (which means the task goes to the backlog).
  • Design element: The game design model element the task 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.
  • Platform: The platform the task belongs to. Defaults to none.
  • Due date: Although tasks are done within the scope of a milestone, they can also have their own due date. This is especially useful for tasks related to marketing, PR or other disciplines that are a bit independent from the development iterations, but we recommend not to overuse this feature. It defaults to none.
  • Description: Add a complete description, links, pictures, and everything that is necessary to clarify what needs to be done in this task. This field supports markdown syntax, so you can format the text as you wish.

Additionally, premium users have and additional tab on the task creation dialog for adding extra information to the task, which otherwise would be added after creation:

  • Subtasks: You can easily add subtasks, a checklist of steps that need to be accomplished before completing the task. The subtasks work well as a reminder and also show a more detailed progress status.
  • Attachments: You can attach files to the task from your computer or Google Drive, that you can also reference from the task description.
  • Dependencies: Dependencies are tasks which block the current one until they are completed, as a way of visually detecting bottlenecks and making the prioritization of tasks easier.
Tip: If you want to create several tasks in a row, check the option “Save & continue” at the bottom left corner of the creation dialog, this will open up another dialog automatically after creating the task for the current one.

 

hacknplan

This entry has 0 replies

Comments are closed.