Welcome to HacknPlan user guide!
Although our website is responsive and can be properly displayed on mobile devices, we don’t currently support mobile officially, so we can not guarantee the web application will work properly on your phone or tablet.
You can create a HacknPlan Personal account for free from here. You can either register filling out the registration form or using the external authentication through Google.
You can cancel your account at any time by going to Settings->My account and clicking on the Delete account button. Bear in mind all your data will be erased permanently, so be precautious.
If you want to know more about the status and the future of the development of HacknPlan, you can read:
If you have other questions:
What is HacknPlan?
HacknPlan is a project management application for game development, that brings game design and task management together to provide a better workflow for game development teams.
Although it does not follow a specific one, the tool heavily inspired by agile methodologies. This is the reason why the application revolves around the kanban board as the main tool to track the progress of your tasks. Defining meaningful, small and well-defined tasks from your functional requirements, and then putting them on our board, will help you easily check the status of the project and keep everything under control.
However, if we think of a project with the scope of a game, having everything in just one board would become a mess to manage. We believe the board should contain a limited amount of tasks in order to provide clarity, otherwise, the excess of information could make you lose sight of what is important and, even worse, commit mistakes. HacknPlan is designed to encourage incremental development as a solution to this problem: we divide the work in Milestones (or iterations) that contain a limited amount of work to be accomplished within a period of time. Ideally, the outcome of every milestone would be a playable version of your game.
So, basically, our project is divided into small tasks and those tasks are grouped into milestones to be accomplished iteratively over time. At the same time, those tasks can be assigned to members of the team, so you can easily see who is working on what.
What about game development?
As you can see, everything explained above is pretty generic and can be applied to any kind of project. How is HacknPlan oriented to game development then? Up to now, we have covered how to organize your work in terms of size (work divided into tasks and different team members) and time (tasks assigned to milestones). So we could say we are defining the how (tasks, resources) and the when (milestones, deadlines) but we still lack another big part of a project: the what.
So, what is “the what” in a game? Simplifying a lot, we could say “the what” is the game design, the definition of what we want to build. And how is this definition normally specified and documented in game development? Yes, as a game design document (GDD). However, traditional project management tool have always been more focused on “the how” and “the when”: tasks, milestones, deadlines, users, time tracking… keeping “the what” a bit outside of the picture, as something that’s normally assumed to be there. That’s probably a reminiscence from waterfall times, where these kind of specification documents were some kind of contract written before starting the project. Agile methodologies like Scrum go a bit further, having the backlog and user stories as a way of knowing your roadmap and having a definition of the features to implement. However, they are designed as lists and don’t have the depth and context a GDD should have. So our mission, as a tool that is for game developers only, is to close the gap between the game design and the project management, creating a streamlined workflow that makes the process of keeping this information updated easier and gives clarity to the producers and the development team.
How do we manage to do that? We provide several tools:
- Game design model. The game design model is a tree structure of elements that can be used to build a hierarchy of concepts and features which tasks can be assigned to. Why a tree? Because it allows you to define interesting structures like worlds with levels inside, towns with other locations inside, menu structures, characters, mechanics… The possibilities are endless. This tool allows you to build a lightweight and dynamic version of your GDD that is attached to your tasks as epics or user stories are, closing the gap between both worlds.
- Role-based categorization. Game development is very multidisciplinary, more than any other software development field, being closer to others like cinema (art, music, writing, sound design…). We have designed a categorization system for tasks, where we assign tasks to these disciplines and then we automatically create a board per each one under the same milestone. This way people working on these categories can focus on their work, but also navigate through all the other categories with a single click, including a global one to take a look at the big picture. We provide a default set of game development categories and sub-categories ready to use, and you can enrich those adding your own ones.
5 tips to better use HacknPlan
In order to get the most out of the tool and improve the organization of your project, we recommend you to follow these small tips:
- Create small tasks: Dealing with big tasks is more complex and overwhelming, so we recommend to take some time to break them down to a reasonable size. If you find yourself thinking our sub-tasks should have more features or be more complex (they are just a checklist), that probably means your tasks are too big and worth being split.
- Avoid multitasking: Try not to put many tasks in progress at the same time and, if you need to put on several hats inside your team, try to group tasks of the same type together and work in batches. Switching context is costly and affects concentration and productivity, so the less you do it, the better.
- Iterate: Iterative development is a nice way of perceiving progress, reducing risk and simplifying your scope, which allows you to focus better. We provide milestones with deadlines as a generic way to create iterations but we don’t enforce a specific way to define them. However, defining short and time-boxed milestones (like sprints in Scrum) is very recommended, as allows you to be constantly evaluating yourself and that’s very positive.
- Use a dedicated time for planning: If you plan things as you go or as ideas come to your mind, you may not be looking at the big picture and could make mistakes or overcomplicate your roadmap. We recommend dedicating recurrent sessions to evaluate what’s going on and plan for the future.
- Keep the tool updated: Sometimes may seem that you or your team are spending too much time on keeping HacknPlan updated. However, despite this could look as a waste of time, it’s very positive for a number of reasons:
- It removes uncertainty and aligns your team.
- It avoids errors or misunderstandings about what has to be done.
- It gives you a perception of progress and achievement.
- It allows you to evaluate yourself, and coming back to past tasks and see what you did and how can help you in many ways.
Setting up a project
HacknPlan allows you to create as many projects as you want. The system is designed in a way that works better when everything in your game is managed under a single project (at least in the Personal version, the Studio version will provide better multi-project management), but you could also split your game into several HacknPlan projects. An example could be a game with a custom engine or level editor, in that case isolating the tools and the game could be convenient.
Creating a project
In order to create a new project, click on the “+Create” button on the Personal Projects panel of the front page of the HacknPlan application. You can also create it by either clicking on Projects->Create project on the top menu or pressing “P” on your keyboard. A new creation dialog is open with the following fields:
- Name: The name of your game.
- Description: A brief description of what your game is about. This is just a small text for informative purposes, especially when you are working on several small projects, not meant for detailed or formatted descriptions.
- Cost metric: This value indicates which metric you would like to use in order to estimate and measure the cost and effort of making a task. The currently supported values are hours, days and, for those who use relative estimations, points. Note: The hours and days will be soon replaced by a more advanced time-based metric that will automatically display minutes, hours or even days depending on your hours per day relation.
These values can be modified at any moment after the project is created.
The project structure
A HacknPlan project is nothing but a big collection of tasks. The task is the main entity in the system, the minimum work unit, and everything revolves around it. Milestones, design elements and categories are just ways to group tasks by certain criteria, which in this case would be time, concept and role, respectively. In order to be able to manage tasks and all these groups and relations, HacknPlan provides several tools or sections:
- Summary: This section gives you a quick overview of the project and allows you to manage your team and the milestones you created. It also displays some metrics about your progress, how many tasks you created, completed and how much time or points you estimated and used.
- The boards: HacknPlan provides a kanban board per milestone as a way to keep track of your work in progress. It also provides sub-boards by task category. This is where you will spend most of the time, picking tasks, moving them to different status columns, and closing them eventually.
- The metrics: This section gives you insights about how your project is going, how much effort you put into each type of job you do and how well are you estimating your work.
- The game design model: Define a tree structure which represents the features and concepts of your game, elaborate them by adding text, pictures or links, and attach tasks to those elements, like a dynamic version of a GDD.
- Administration: Configure your project and customize your categories and other classification elements.
When you are in a planning session, you will mostly work from the game design model section, designing the structure of your features and general concepts and envisioning the high-level roadmap of your game, and will probably distribute many of those tasks among different upcoming milestones. You will also take a look at the metrics section to evaluate the estimation of your pending work and see if it’s viable over time.
However, once your planning for the near future is done, you will start your milestones and will focus on the short term, on achieving the next goal. And the kanban board will be your home then, keeping track of the progress of the tasks, commenting, adding screenshots, enriching them… You will also take a look at the metrics of the current milestone in order to see how is it going.
Adding your team
HacknPlan is a collaborative tool, especially useful for teams, so you can add other users to your project. In the Summary section, click on the “Add” button of the Members panel. This will launch a dialog where you can input the email address of the user to be added.
There are two checkboxes:
- Send an invitation email if the user is not registered: When the email you insert does not belong to an existing HacknPlan user, an email is sent inviting the user to register. When the user does so, they are automatically added to the project.
- The new user is administrator of the project: The user is automatically provided with administrative rights, which allows them to add other users, create milestones, update the game model and many other actions.
After adding users to a project, you would probably like to edit their permissions. HacknPlan offers simple permission scheme based on the existing categories. This allows you to have control over which kind of tasks each user can see or modify. Click on the pencil icon on the Members panel of the Summary section to open the access edition dialog.
You can set a different access level for each one of the categories in your project, which goes from no access at all to full edition permissions:
- No access: The user won’t be able to see any information (including tasks and metrics) about the category.
- Read only: The user can access to the category data (board, tasks, metrics…) but can’t create, modify or delete any of it.
- Update only: The user can perform a very limited set of actions, oriented to update the tasks they have been assigned to, but can’t create or delete anything, nor modify most information of the tasks in the category like category, milestone, description or assigned users. This level is very useful for users with very limited power within your team, like contractors or temporary employees. The list of available actions are:
- Move assigned tasks among status columns and sort them using drag and drop.
- Update the current cost (in order to report progress).
- Complete or re-open sub-tasks.
- Add attachments and set them as cover.
- Add comments.
- Full write: The user can create, edit and delete tasks from the category.
You can also give project administration rights to a user, which not only gives full permissions for all categories, but also allows them to manage project master data like categories, subcategories and element types, or edit the game design model.
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 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 Planned stage.
Besides the stage, during the lifetime of a task, it can be assigned to one or several users in the project. 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” 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 / urgent 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.
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.
The kanban board
The game design model
If there is a feature in HacknPlan which is unique and completely game dev oriented, is the game design model (GDM). One of the most common pains development teams suffer when working on a game is the difficulty of defining a proper game design document (GDD) and, most importantly, keeping it updated and alive. This is key for a proper project organization because it’s the resource used to define your vision of the game and to keep your team aligned. The way projects are managed has changed a lot over the years; there was a time when having a fixed document containing the full design of a game from the beginning was accepted; that’s how the waterfall methodology worked. However, in today’s world, projects are approached in a more agile and iterative way which encourages prototyping, iteration, and constant evaluation. The GDD is now a document in constant evolution, being built iteratively as the game does.
The purpose behind the GDM is to provide a dynamic and integrated way of defining your game design, replacing the linear document or wiki pages with a tree structure of design elements which not only contain unstructured content like text and pictures, but also tasks, progress, and metrics. This way, your tasks are not just a bunch of tickets on a list, they have something that connects them as a whole giving context and meaning, and at the same time your design is not isolated from the project itself, it has a new dimension now, which is how that design is implemented over time.
Defining your design model
Important: The game design model requires specific writing permissions.
You can create a new design element by clicking on the “Create element” button on the header or by pressing C on your keyboard from the game design model section. You can also create a child element to another one by clicking on “Add child element” on the context menu (right click or gear icon), or clone it by clicking on “Clone” or pressing “Alt”+”C” on the keyboard.
When a new element is created, it’s automatically selected and a panel is open for editing several fields like the name of the element, the type (a categorization value to give it more meaning) and a description, which contains the definition of the design element with text, links, and pictures. The content of the design element can be formatted using Markdown syntax for a better display, and also supports html in order to create more advanced layouts. After your element is created, you can update it at any time by selecting the element from the tree. There are a few shortcuts to go directly to the edition of the name, you can open the context menu and click “Edit” or press “E” on your keyboard while the element is selected.
Besides editing the fields we already mentioned, you can also relocate the design element by using drag and drop. You can also drop an element as a child of another one by dragging the element below the parent and then moving the mouse to the right before dropping, which will indent the placeholder as a visual representation of this process. For this operation to work, the parent element needs to be expanded if already has children.
You can delete design elements by clicking “Delete” on the context menu or by pressing “Del” key while the element is selected.
Adding tasks to your design model
One of the biggest advantages of the GDM over a traditional GDD is the direct relation between design and planning, and this is achieved by connecting design elements and tasks. These two entities, along with the definition of milestones / iterations, connect the tree basic pillars of a project: what to do (GDM), how to do it (Tasks / Team), and when (Milestones / Deadlines).
Adding a task to a design model is as simple as creating a new task like we explained earlier in this guide. The creation dialog will allow you to choose the desired game design element, including the possibility of leaving it blank to create a detached task, although we strongly recommend putting everything under the GDM for a better organization. When you create a task while in the GDM section and an element is selected, the task creation will have that element selected by default.
The tasks belonging to a specific design element are listed under the “Tasks” tab of the design element editor. You can also see the design element of a task at the top of the cards in the
kanban boards, which helps to quickly identify them. If you want to move a task from one design element to another one, you can do so by opening the task editor by selecting a task from the GDM or the board and then clicking on the design element field. You can also change the design element of a task from the context menu.
Milestones and deadlines
In HacknPlan, a milestone represents a group of tasks that are meant to be accomplished within a period of time, and one of its main purposes is scaling the scope down to a manageable size and set partial goals in order to better measure the progress of the project. A milestone can be of any size and frequency, although we strongly recommend to use them as iterations and create short timeboxed milestones. Making them short allows you to evaluate the progress more frequently, hence issues can be detected and fixed earlier.
Each milestone has a dedicated kanban board where the progress of the tasks is tracked. In a typical agile workflow, tasks would be added to the backlog where they are enriched, sorted by priority and, once they are ready, they would be added to a milestone for future implementation. Once it’s time for the milestone to begin, the team will start working on the tasks inside and, eventually (and hopefully on time and with every task completed), the milestone would be marked as finished and archived.
Creating a milestone
To create a new milestone, go to the Summary section of your project (Milestone section for Studio projects) and click on the “+ Add” button on the Milestones panel, or press ‘M’ on your keyboard. This will open up a dialog to enter some basic information about the milestone:
- Name: The name of the milestone which will be used to reference it in different parts of the application. If you are using some sort of agile iteration method, this could be something like ‘Sprint 1’, or maybe a more classic version number like ‘v0.3.2’.
- Description: This is a short description that is displayed on milestone lists, and its purpose is to help localize them better. It could contain a small summary of the features planned for the milestone.
- Start date: This date determines when the milestone starts. This value is very important, as it will affect how metrics are calculated and will keep the estimations meaningful. We’ll explain this in more detail in the metrics chapter.
- Due date: This date is the expected finishing date (or deadline) of the milestone. This one does not affect metrics, it’s informative only, but it’s very helpful in order to manage development times and create a roadmap.
Working with milestones
When you are working on a milestone, you might want it to be opened by default when you access the kanban board or selected when you are creating tasks. For this to happen, you need to set the milestone as default by clicking on the star icon on the milestone panel (Summary / Milestones section).
You can basically perform 3 different operations on milestones once they are created: edit, finish and delete them. You can edit the name, description, and dates by clicking on the pencil button on the milestone card. You can also delete it by clicking on the trash can button. When a milestone is deleted, all the tasks inside are moved to the backlog automatically.
Once a milestone has started, you are going to spend most of your time in two sections: the kanban board, for tracking the progress of tasks in the milestone, and the metrics, for getting information about how’s everything going compared to your initial estimations. Both sections have a milestone selector at the top right corner of the page, so you can quickly switch to any of them including the finished ones. It also displays a reminder of how many time is left until the deadline you set, and a button that will allow you archive the milestone once it’s finished.
The metrics page provide several stats to evaluate the milestone by comparing the outcome with the initial estimations.
- Estimated: The number of tasks estimated for the milestone. This field is calculated differently depending on whether the start date of the milestone is set or not. When the start date is not set, this field just displays the sum of all tasks in the milestone. However, when the start date is set, it’s used to determine the scope of the milestone better and the estimated metric is frozen at the sum of all tasks at the moment of starting the milestone. Why is that? The goal of this is keeping the real initial estimations of a milestone no matter what happens with tasks inside; if they are moved, estimations change or whatever. This is the best way to keep meaningful metrics of past milestones you can come back to.
- Estimated variation: When the start date is set, this metric is shown to specify the difference between the initial estimation vs the current sum of tasks in the milestone. This is very useful to see if the milestone scope is varying too much after starting the milestone.
- Pending: The number of tasks in the milestone which are not yet completed.
- Completed: The number of tasks in the milestone that were moved to the completed column.
- Progress: The percentage of completed tasks vs the pending ones.
- Estimated: The amount of effort (time or points) estimated for the milestone. Exactly like the estimated metric for tasks, this one shows the sum of estimated cost values in all tasks at the moment of starting the milestone when the start date is set.
- Estimated variation: Same than for tasks, shows the difference between the initial estimation and the current sum of task estimations.
- Logged: The amount of effort logged into the tasks in the milestone.
- Remaining: The difference between the estimated cost and the currently logged one.
- Progress: The percentage of logged cost vs the initial estimation.
Filtering and sorting
You can integrate HacknPlan with GitHub in order to link commits to tasks automatically and display them in the task editor. This is very useful for tracking purposes since it allows you to easily find the list of changes done for a specific task, and also keeps you notified when it happens.
The first step for the integration to work is linking your HacknPlan and GitHub accounts (unless you are already registered / logged using GitHub, then you can skip this step). Bear in mind you need to have administration rights on both sides (the HacknPlan project and the GitHub repository you want to integrate). Go to your user settings page (clicking on your avatar at the top-right corner of the application -> Settings) and then select Integrations from the left menu. There you can see a list of your current 3rd party integrations. Click on Link external account and then select GitHub. This should redirect you to GitHub in order to approve the request for authentication from HacknPlan.
Once the accounts are linked, you need to use those credentials to establish a connection between one of the HacknPlan projects you manage and a repository. Go to your project administration page (click on project icon on the left menu and the select the Admin tab) and then click on the Integrations sub-tab. Click on the Connect repository button under the GitHub panel, which will open a popup dialog. Here you can select the GitHub account you previously linked (you can have more than one GitHub account linked to a single HacknPlan account) and then you can select a repository which will be populated with the list of your available repositories. Click on Connect and… voila!, your project and your GitHub repo are now linked.
Note: This process may fail if your GitHub account was linked before this feature was released. We didn’t ask for some access rights before that are now needed for this integration to work. If this happens, you have two options to refresh the integration: delete the link from the user Settings page and add it again or, if you registered using GitHub, log out from HacknPlan, revoke the integration from GitHub and log in again.
So, how can I link a commit to a HacknPlan task now? Easy, you just have to reference the HacknPlan’s task ID from the commit message using the hash sign , something like #10 or #223. When the commit is pushed, the information will be sent to HacknPlan and the message will be analyzed to find tasks inside, and if one or more are found, the commit will be linked to them and shown under the Source Code tab of the task editor, including a link to the commit details in GitHub. This event will also show up on the activity log, and a notification will be sent to the involved users if it’s configured properly.
You can disconnect a repository from a project at any moment by clicking on the Disconnect button on the integration page. This will prevent any more commits to be tracked, but the existing ones will be kept for historical / logging reasons.