Concepts in Agilefant
There are three kinds of backlogs in Agilefant: Products, Projects, and Iterations. The product backlog contains “everything” that may be needed to be done. Out of this, you split and plan a set of stories to be done in a project, and move the stories into the project. There, you further split the stories, choose a scope for an iteration, and move the stories into the iteration.
The relationship of these backlogs is illustrated below:
Product is the generic term used for something the organization is developing such as a piece of software or service. In Agilefant you can have as many products as you want.
Some organizations using Agilefant use products to represent specific customers – or even entire business areas. You can create new products by clicking the ‘Create new’ button in the top left corner of the page. When creating a product, define at least one team that has access to that product. Otherwise, only admin users can see and access the created product. You can change this later from Administration -> Access rights.
Products are developed in projects. You can think of projects as ’major releases’ or important milestones (although nothing restricts you from releasing as often as you wish – once per each iteration or story, and so on) – see the example backlog structure below.
As projects have a start and an end date, think about a scope which is important to you to track regarding progress versus a deadline, and make that as your project.
Projects can be created from the Create new button. Projects are always related to a single product, so you can not create projects before products (making this more flexible is in the roadmap). However, there can be parallel projects under a single product. For example, it’s also possible to handle different project by each team.
Project burn-up displays the progress of the project in terms of story points. It depicts the points in Done stories (the green area) against the total scope of the project. Using the historical velocity, the graph illustrates whether the project is progressing on time or not. You can choose how far from the history it calculates the velocity. Additionally, you can compare the estimated day of completion to the project’s end date so you know if changes in scope may be needed.
The blue line displays the amount of points in stories that are split into small enough units so that they can be fed forward into implementation. This threshold value (in story points) can be adjusted and depends on the project. The gray line displays the total scope. The difference between these lines is the sum of work that’s still “too big” – that is, it should be split into smaller stories before implementation. Even if you don’t use story points in your project, you can use the burn-up graph by defining how it should point unestimated stories — you can for example define that each story is a size of one story point. This short video has more information on how to read the burn-up chart.
An iteration is a time-boxed period which is planned in detail in terms of tasks and man-hours. Scrum calls iterations ‘Sprints’. You can create iterations from the Create new menu. There can be many parallel iterations for a single project – for example when multiple teams are working on a single project. Think of for example Dean Leffingwell’s Scaled Agile Framework and the concept of Agile Release Train, where each team has their own “sprint backlog”. You don’t have to create iterations if you don’t need them. Likewise, you don’t have to estimate – or even use tasks – if you don’t need them.
Note that stories order in an iteration is not same as the order in a project. This makes sure that there can be several parallel iterations for several teams which all pull stories from the same project backlog. And when this is the case, there is no a logic way to define the order of stories in the project backlog.
Iteration burndown is a graphical representation of tasks’ progress in the iteration as a function of time. It shows a linear reference based on the sum of the tasks’ original estimates. Thus, if you want to use an iteration burndown chart, you need to split stories into tasks and estimate them.
Iteration burndown chart follows pretty much the basic idea of Scrum burndown. Here’s how to read the burndown chart:
- The sum of effort left in tasks
- When tasks (that have effort left) are added / removed, the graph “jumps” up/down
- When effort left of a task is decreased, the graph descends (slope down) that amount
- When effort left of a task is increased, the graph goes up that amount
- Spent effort can be logged for tasks, stories and the iteration itself
- The effort spent graph displays the sum of the above as function of time
- A line that shows when the effort left is going to be zero if it decreases at same rate it has decreased on the average during the sprint so far
Iterations can also be moved from one project to another, or from under a project as a standalone iteration, and vice versa. You can find the command to move an iteration in the Iteration view behind the Actions button.
When moving an iteration, the stories’ parent-child relationships are kept whenever possible; that is,
- if the iteration is moved from under a project to a standalone (or vice versa) they are kept
- if the parent is in a project and the iteration is moved to another project, the relationship is broken
- if the parent is on the product level, the story parent-child relationship is broken only if the target project is in a different product
Agilefant has a special iteration type called ‘Standalone iteration’. Unlike regular iterations, standalone iterations don’t belong to any project and can include stories from multiple products and projects.
There are two main purposes for standalone iterations. First, the simplest way to adopt Agilefant for iteration management is to create standalone iterations; no need to create structures your team may not (initially) need. You can add structure (for example story hierarchies, products, and projects) as the need arises. Second, standalone iterations can be used to manage the duties of a team which works on multiple products and/or projects. In regular iterations, all stories must belong to the parent project and product. In standalone iterations, stories may come from multiple products and projects, and still, Agilefant knows how to reflect the stories’ status to the project and product level metrics.
As an example, suppose that a team is responsible for both the development of a product, but also supporting a certain customer who is using something that was delivered by the team in a past custom project. To take into account all of the team’s work in iteration planning, it may be useful to have the team use standalone iterations, as these may include both product development and support related stories.
Standalone iterations are created like regular iterations, with the exception that the ‘parent project’ in the creation dialog is simply left empty. Standalone iterations are special iterations as they have no parent backlog. You can create a standalone iteration as follow:
- Click on the ‘Create new’ link in the upper right-hand corner and choose iteration
- Leave the ‘Parent’ field empty in the iteration creation dialog
Rename a backlog
To edit the name of a backlog, open the backlog from the left side menu and then click its name that is at the top of the page. The edit mode will appear and you can edit the name as you wish.
Delete a product/project/iteration
Open the product/project/iteration in question. Click on ‘Actions’ dropdown menu on the top of the page, and choose ‘Delete’.
Move a backlog
Currently, iterations are the only backlogs that can be moved. Iterations can be moved from one project to another, or from under a project to a standalone and vice versa. You can find the command to move an iteration in the Iteration view behind the Actions button. When moving an iteration, the stories’ parent-child relationships are kept whenever possible; that is, if the iteration is moved from under a project to a standalone (or vice versa) they are kept; if the parent is in a project and the iteration is moved to another project, the relationship is broken; and if the parent is on the product level, the story parent-child relationship is broken only if the target project is in a different product.
Share a burndown chart
You can do this using read-only iterations. You can generate a link to a read-only iteration page by clicking ‘Share’ button (under ‘Actions’ button in the iteration view). Share this link to anyone you want to have read-only access to the iteration.
Selecting a default backlog
Default backlogs are used to have one place where to put stories and tasks when it is not obvious from the context where they should be, e.g. when you create new items in the My Work view. Note that when you create stories and tasks in an iteration, project or product, the items will be added to those backlogs.
The default backlog is particularly useful when you just want to write down something quickly and worry about the correct context later. That is, to which backlog the item should go to, whether it should belong inside a story as a task, or whether it should be a child story of some other story.
In newly created accounts, the pre-created user’s default backlog is the ongoing iteration of the example product. You can set your default backlog opening the administration menu in the upper right corner where your display name is shown. In the menu click on “Settings” and the My Settings tab will be open where you can choose your default backlog.
Currently, the default backlog must either be an iteration – either a regular one or a standalone iteration. When the default backlog is set, Agilefant automatically suggests the default backlog as the context for the newly created item, so if you want to quickly just write something down, just type it in, hit enter, and the item goes to the default backlog. Of course, you can still change the context right away as you are creating the item.
Admin users can also set the default backlog for other users. Set the default backlog by clicking “Settings” in the upper right corner. In settings open the “Users” tab and click on the user’s name whose default backlog you want to edit.
Export iteration to Excel
You can export iteration contents as .xls. This can be done by clicking the ‘Export’ link under ‘Actions’ button in iteration view.
See the total points planned for a project
Projects have a burn-up graph that is found under the Burn-up tab in the project backlog view. The burn-up graph shows the history of the story point sum of all stories during the project, as well as the completed ones.
If you have your existing backlog in a structured format (csv, xls or similar) and want to get it imported to Agilefant, please contact our support. Agilefant doesn’t have a feature for import a backlog, but we are happy to help our subscribers importing their existing backlogs; for this, contact support(at)agilefant.com
Copy projects and/or iterations?
Currently, you cannot copy projects or iterations, only stories. If you want to copy the contents of a project, move all the stories first under a single story, and then do a branch copy of that.
Agilefant has two concepts for a piece of work that needs to be done: story and task. In a typical use case stories are separated from tasks in that stories have value when completed (e.g. a new product feature) whereas tasks might not have (e.g. make a prototype of the new feature) – this enables prioritization to be done with stories while tasks can be added to a story for planning and tracking the activities needed for completing the story.
Stories can be anything from business goals, customer requests and features to small issue descriptions.
Agilefant has been designed with story hierarchies in mind; they are actually what we see as the core of really making agile work enterprise-wide, and leverage its benefits for everyone. In other words, in Agilefant there are no concepts such as epics to describe particularly big stories. Instead, you can create a hierarchy of stories by dividing bigger stories to smaller and smaller until you have something that is small enough that it can be added to a project or an iteration.
In Agilefant, a story must always reside in a product, project or an iteration. Stories in the product backlog have no particular priority or ‘schedule’, although you can sort and organize them in the story tree by drag & drop. To schedule stories for development, and to be able to prioritize them in a list view, you move them into a project.
If you want to create a story that does not belong to any product or project, you can create a standalone iteration (called for example ‘inbox’) and create the stories first there. Then you can move them into the products or projects (or iterations) you desire.
The order of stories differs across a product, project, iteration, and my work. The first reason is that things would get difficult when there are multiple parallel iterations – it is impossible automatically to deduct the absolute order of the parallel iterations’ contents. Rather, if the absolute order of, say, stories in three parallel iterations is useful to express, this can be done on the project level. The second reason is that having an independent order on the project level makes it possible for the project level plan to “freeze” when the sprint is planned. Then, as the sprint goes forward, things change and stories are re-ordered, a comparison to the original plan is still possible for learning (etc.) purposes.
Effort estimation – points
The relative size of stories can be estimated in so-called story points. Note that you can use instead of story points other measures like person days, but in this section, we will describe how story points are used.
Several agile teams around the globe are using an exponential scale when estimating story points. This is because as the size of a story gets bigger, it’s increasingly harder to say the difference between N and N – 1. One option to estimate story points is to use the Fibonacci scale. This is one of many options, but probably the most popular. When using this scale, stories are estimated using points 1, 2, 3, 5, 8, 13 and so on. This means that a story of one point requires approximately half less work than a story of two story points. When talking about small stories it might be quite easy to say that this one is expected to be twice as complex as another one. But when you are talking about larger stories, it becomes more difficult to draw the line between, let’s say, 6, 7, and 8 points. It’s pretty much same as it’s much easier to say whether you need 2 or 4 hours to finish your task whereas it’s pretty demanding to estimate if you need 16 or 18 hours to finish a task. The same applies to story points. Though you should not equate points to calendar time from the start, our long-term experience from using story points at Agilefant has converged to something like the following: One point means that we can do the story without a break; two points require a half day of work; three points require a day of work; five points two days, and eight points a week. If a story requires more than eight points, we break it into smaller stories. You can read more about the concept of story points – and why they are useful compared to estimating in man-hours from a blog post by one of Scrum’s inventors, Jeff Sutherland. There’s plenty of useful material on story points around the Internet, so look it up if you have questions on how to use them.
Stories (and tasks) have pre-defined states. You can think about their meaning as follows: The following states have ‘special effects’:
- Done – the final state of a task/story after it’s been completed. Affects the related metrics.
- Deferred – the task/story has been decided to be skipped in this project/iteration; the effort left / points are omitted in all metrics. This can be used to quickly scope out stories / tasks without having to move them to a different backlog.
The other states are:
- Not Started – No work has yet been put into realizing this story
- In Progress – ongoing and some work has already been put in
- Pending – waiting for something external that can reasonably be expected to happen without us taking any further action
- Blocked – can’t proceed; most likely some action must be taken by ‘us’ before work can proceed
- Ready – otherwise done, but some relatively minor definition-of-done criteria are yet to be met; e.g. the story must be demoed to the product owner / released to the public / brought up in the stand-up …and so on.
Sometimes we have been asked if states can be customized. Currently you can’t. However, customized states are on our roadmap and we will eventually implement them.
Stories may also be assigned a business value (‘value’ in Agilefant). Values are not currently used in any calculations, but those can be used as a support of decision making, for example, in planning.
Start, planned start, end, and due dates
A start date is the moment of time when a story is set from ‘Not started’ state to any other state. If the state is changed back to ‘Not started’ state, the start date will be cleared.
An end date is the moment of time when a story is set from any other state to either ‘Done’ or ‘Deferred’ state. If the state is changed back to another state than Done or Deferred, the end date will be cleared.
A planned start date is manually entered, used to tell the date when a story should be started. In a story details view, if story is started, the start d
A due date is also set manually; it tells the date a story should be finished.
The story details view shows the start date if a story is started. This can be overridden by selecting an alternative start date, i.e. a planned start date. This will replace the start date in the details view. However, if you clear the planned start date and story is still started, the actual start date will come visible.
When a story is set either ‘Done’ or ‘Deferred’, a story’s lead time and cycle time will come visibly in the story details. The lead time is the time between the moment when a story was set either Done or Deferred and the moment the story was created. The Cycle time is the time between the moment when the story was started (set from Not started state to another state) and the moment when the story was finished (either Done or Deferred state).
Stories can be labeled. For example, you might want to label stories according to whether they are bugs, usability improvements, strategic new cool things, being planned for release this-and-that, and so on. This can be done from the ‘story details’ view. Additionally, if you are looking for ‘Themes’, labels are what you need.
Unlike in most tools, where you are forced to use labels to group features into “business themes” or “epics”, you can in Agilefant use the story tree for that, and reserve labels for other purposes. For example, we use labels to denote where a certain figure has come from (for example, our community forums, an important customer X, and so on). As another example, one customer organization conducts half-year product development projects but does intermediate releases in between, and uses labels to denote the release in which a certain feature is estimated to get done.
Agilefant also allows you to edit existing labels. You can rename them, delete them, and merge them with other labels. You find label editor in Settings under ‘Label editor’ tab. Note that you need admin rights to access this view.
From the labels list, you can see the number of stories the label is added to, and the number of filters that use the story in question.
Merge is handy when you have similar labels, and you want to combine them. To merge labels, select the ones you want to merge and click ‘Merge labels’ from the bottom right corner. From the dialog, choose the label you want to merge the others into. All unselected labels will be removed from stories and filters and replaced with the chosen one.
You can set up stories to be depended on other stories, or be required by other stories (see below). The dependencies are set via a search dialog (which allows selecting any story from any product) which opens from story attributes. When a dependency has been set, you can see it, as well as the related stories’ states and possible due dates from both of the concerned stories. You can also navigate to the related story to view it more closely.
Dependencies are visualized in a story tree and boards using circular up and down arrows. A down arrow means that the story depends on other stories, and an up arrow means the story is required by other stories. You can see the dependency stories by hovering the arrow.
You can upload attachments to stories. In a story tree view you click on the story and open the ‘Description tab’ and in a story list view (e.g. a project’s leaf stories view) you can add attachments by expanding the story and selecting the attachments view. In both cases drop the files you want to attach onto the drop area, or click it and choose files. You can also attach files and images via the description editor. Click either ‘Upload file’ or ‘Insert image’ button and choose files.
If you want to upload documents to tasks or backlogs, you can upload files and other attachments to some cloud service (e.g. Dropbox, Box, or Drive) and then link them into Agilefant using the description field of a product/project/iteration/story/task.
To add a link to a file, click on the description field to make it active, click ‘Insert Link’ button, add the URL of the document and then click OK.
Unless otherwise agreed, each organization has 1GB space for attachments and the maximum size of a single file is 10MB.
Create a story
You can create stories directly to a backlog from the green ‘+’ button located on the right side top of the story list and story tree, and from the ‘Create new’ button.
Delete a story
In a story tree view, you can delete stories via the right-hand side pencil icon where you select ‘Delete’. In a story list view, the Delete option is behind the right-hand side overflow (triple dot) menu.
There’s no Undo currently, but if you’ve deleted (or otherwise lost) something important and you’re a Cloud user, we are happy to retrieve it from the backups for you! Reach us out via lower left-hand corner chat and tell us your account name (see cloud.agilefant.com/ACCOUNTNAME), what you want to be retrieved, and time, when the list things for sure were still there.
Prioritize and organize stories
Moving a story from a backlog to another (for example, from a product to a project – or from a project to an iteration, or vice versa), represents a coarse-grained prioritization of the story. In other words, when, approximately is the story about to be developed.
Within projects and iterations, this “backlog-based” priority can be detailed further by drag & dropping stories up and down in the force-ranked lists (called ‘Leaf stories’ and ‘List’ on the project and iteration levels, respectively). The overflow (three dots) menu has an option to put a story to the top or to bottom, which can be convenient when prioritizing a longer list of stories.
The final place to set priorities for tasks and stories – although this affects the user doing the “prioritization” is in the task and story queues of the My Work tab. This kind of “prioritization” is just for the individual for his personal planning purposes – for example, “that is the thing I can do right now with the time that I have left.”
Story trees are places where you can do and re-organize the work breakdown. You can have a hierarchy as deep as you wish. The only limitation is that only leaf stories (that is, stories that do not have child stories) can be put into iterations. While in the tree views stories “remember” where they are in relation to each other, the ordering there does not at this point represent priority.
Project leaf stories and stories in iteration can be prioritized by drag-and-dropping them to the correct order (most important at the top). On the product level, ‘prioritization’ of leaf stories is done by moving the story to the correct project and / or iteration. Parent stories (= stories with children) can’t be prioritized, as this would make little sense – for example, “are all child stories of Feature X more important than all child stories of Feature Y”.
Create tasks to a story
In Agilefant, there are many ways to create tasks inside stories:
- In a story list view click on the arrow icon to expand the story and when selecting the Tasks view you can see the ‘Add task’ button
- In a story tree view, click on the story, open the Tasks tab and you will find the ‘Add task’ button
Split unfinished stories
If you need to split an unfinished story, the easiest way to do it is to use the ‘Extract unfinished’ action that you can find the overflow (three dots) menu. This creates a copy of the story in question and moves all tasks which are not done to the newly created story. All the done tasks and all effort spent will remain in the original story.
Another option is to use the ‘Copy’ feature in the overflow menu. This copies all the tasks, their states, story points, effort left (but not effort spent), so you just rename the old story to what got done, rename the new story to what’s left, and then delete extra tasks from both.
Remove a story from its iteration
There are many options to remove a story from an iteration:
- Open the iteration and drag and drop the story to another backlog (product, project or iteration)
- In the iteration story view or the project leaf story view, click the overflow (three dot) menu and select ‘Remove from iteration‘
- In the story tree view, click the pen menu and select ‘Move‘
Move stories from one backlog to another
There are several ways to move stories and tasks from one backlog to another in Agilefant:
- Drag & drop a story from a list view (My work, Iteration, Leaf stories) to the left-hand backlog tree
- Drag & drop a story from the story tree view to the left-hand backlog tree; if the story has children, they are taken along as well
- Select a product, project and/or iteration in the story info dialog which opens up when you click on a story in the story tree view
- Open the edit menu for the task / story (that’s the overflow (three dots) icon at the right-hand end of each row in list views) and then selecting “Move”
Note, that currently, stories in an iteration can’t have children. Thus, if you move a story with children to an iteration, the parent-child relationships will be gone, the child stories won’t come along, and will become root stories.
Move stories to an iteration
You can move stories both in a story tree and a list view.
From the story tree:
- From the left-hand side ‘Backlogs’ menu, expand backlogs so that the iteration is visible. Then drag and drop the story to the iteration located in the ‘Backlogs’ tree. You can also move multiple stories at once by first selecting the stories you want to move using the checkbox.
- Click the story and ‘Story Info’ dialog will appear. Select the iteration from the Summary tab.
- Hover on top of the story and click the pencil icon. Click ‘Move’ and select the iteration to where you want to move the story.
From the list view:
- You can both drag & drop the story and selecting move it in the overflow (three dot) menu.
In all the story list view (My Work, Project’s Leaf Stories, Iteration), there is an Copy functionality in the overflow (three dot) menu.
A task is something relatively well-defined and effort-wise small that needs to get done. Each story can contain one or more tasks. In addition, there can be tasks which are not linked to any stories. These are called task without stories. This can be the case if, for example, something is so small that a new story is not needed.
Tasks are estimated in man-hours. Effort left is what you estimate is still left to complete the task. Note, that while a story also shows ‘Effort left’, this is not a property of the story itself but is summed up from its tasks. The first estimate for a task becomes its “original estimate”. Original estimates affect the iteration burndown’s estimate line but have no further effect on other metrics. You can reset the original estimate from the pencil icon of the task or by clicking the ‘Original estimate’ field when the task is expanded. Tasks also have spent effort property that is the effort you have already used working on it.
To add tasks to a story, open a story details view. In the My Work view, the Iteration view and the Project leaf stories view, click on the arrow icon. In the story tree and the board view, click on the story. From the story details view, you will find the Add task button:
You can edit tasks of stories in all views you have access to them: for example, an iteration, a project, a product, or the ‘My work’ view. Tasks can be added also to a higher level parent story which does not show up in list views, you can still create tasks for it as it shows up in the ‘My work’ view. This is because sometimes it makes sense to create tasks to a parent story; for example, the product owner might have tasks related to moving the higher level feature onwards in various ways, while the development team is working on the implementation in sprints.
Move a task without a story into a story
Tasks without stories can be drag and dropped to a story in the My Work view. Drag the task first to the Story tab which will open the story list, then move the task to the story you want.
Move tasks from one story to another
You can move tasks from one story to another. This is can be done in all story list views: ‘My work’, ‘Leaf stories’ and ‘Stories’ view in an Iteration. Expand the story by pressing the arrow and open the task view of both the story where the task is currently and the story where you want to move the task. Next, you simply drag and drop the task to the new host story.
Definition of effort left and how to update it
The effort left (simple ‘Left’ in the user interface) is your best estimate of time needed to finish the task/story. As this can (and often does) change as you work with the task/story, it must always be updated manually.
Let’s take an example: If you originally estimate a task to be 10h (original estimate = the first estimated effort left = 10h) and after you’ve spent 8h, you still think that it’ll take 8h to finish, you log 8 more hours to spent and update Left to 8h. Later, you work 5 more hours and finish the task. So, you put 5 more hours to Spent and you have spent 13h in total on that task. Now you should also set Left to zero (because the task is finished). Note: if you set the task ‘Done’, the left will automatically go to zero.
You can enter effort left directly to a task by clicking the Left field. You can also update the effort left when you enter spent effort it ‘Spent’ dialog.
In Agilefant, you can log spent effort at the granularity that’s needed: to tasks, stories, iterations, projects, and products. Logging effort to Products, Projects, and Iterations is done via the Actions menu. This is located on the menu bar.
To log effort for a story or task you can do it in all views were tasks or stories are visible. Just open the story or task details view and click on the spent effort.
In the story tree views, you can also left-click on a story and choose ‘Spent effort’ from the menu.
Agilefant keeps track of how long has passed since you last entered spent effort and offers that as the default value for next spent effort. The time since last entry is always visible in the upper right corner. You can reset the clock to zero by clicking it for instance when you start your day. The clock is automatically reset to zero after 8 hours without any effort spent entries.
To see how much spent-effort you have entered, click on any story’s or task’s spent column and the effort spent dialog will open where you can see the information.
You have the same information available in the My work view.
Users can be set as responsible for stories and tasks. This can be used to indicate who is working on what. To do this, click the Who / Responsibles field of a story or a task, and select users who will perform the story/task. In some organizations, features are at first assigned to an entire team instead of individual users. If you wish to do this in Agilefant, simply create a user to represent a team, and assign the story to that “user”. Then, as the time comes, the team can assign the story – or parts of it – inside the team to individuals. Note, task responsibilities are not propagated upwards to stories. Story’s responsibilities field can be ‘none’ even though the story has task level responsibilities.
Iterations and projects also have a similar property, called assignees. The purpose of this field is to list on project and iteration level the peoples participating in them. For now, the assignees are not same as Agilefant teams.
There are two types of users in Agilefant – admins and regular users. Admin users can do anything, whereas regular users have certain limits to what they are able to do; for example, they are not able to edit other users’ info, set access rights, edit teams, export the database and so on. However, they can create new users, which automatically belong to the same team(s) as the user which created them.
Create a user
To invite a new user, click top left ‘Create new’ and then ‘User’. An automatically generated password is sent to the new user’s e-mail address. Note that users’ login names must be unique, so if the person you’re inviting has also signed for an Agilefant account, there are good chances that the email is already taken. In that case, ask your friend to change his login name in his account, or reach out in chat for help.
Disable a user
Currently, you can’t delete users but only disable them. You will not be billed for disabled users.
Change a password
To change your password, click your name in the top-right corner of the page and select ‘My settings’ from the dropdown menu. This will take you to your user page. The Change password button is at the bottom of the page.
If you lose or forget your password, you can request a new password via this link: Forgot a password? Alternatively, if there is an admin user in your account who can log in, you can ask her to reset the password for you. If you are unable to reset the password, email us and we will help you out.
Teams have an essential role in access management. With teams, you can limit people’s access to products and standalone iterations. You will be introduced to the access rights right after this part.
Create a team
You can create teams using the ‘Create new’ button or from the Teams page in the Administration menu. When you are creating a team, you will be asked to give the name of the team and users who will be part of the team, and whether the team has access to all products and standalone iterations.
Admin users are distinct from regular users. Regular users have certain limits to what they are able to do (see below), whereas admins are allowed to do anything. Basically, admin users can limit which teams are able to access which product or standalone iteration. For example, when you are working on a certain product with a subcontractor, you can create users for them, add these users to a team, and set the team to access that and only that product. Or, if you have modeled things so that a particular customer is represented by a product, you can let them have full access to their backlogs.
You can modify access right by clicking settings in the administration menu (i.e. your display name in the upper right corner) and then selecting the Access Right tab. The access rights work as follows:
- Admin users may do anything, non-admin users are limited to the products and iterations their teams have access to. Admin users also can always see and access all backlogs, regardless of access rights settings
- Non-admin users may create new products that their teams have access to and add new users to their teams. for example, editing other users’ info, setting access rights, editing teams, exporting the database and so on
- All users may belong to as many teams as needed
As a default, we recommend that when you are creating teams, you grant them access rights to all products and standalone iterations. Likewise, when you are creating new products or standalone iterations, you grant all teams access rights to them.
Both admin and non-admin users can also share iterations as read-only. Sharing an iteration creates a non-guessable URL token you can send the people you wish to be able to see the stories in the iteration and all the iteration level metrics. For example, you may wish to show the customer how the current iteration is progressing, but for some reason don’t want them to be able to directly edit the backlogs.
The Story Tree is a view that displays how the smaller stories have been refined from the higher level goals and entities. On the product level, the Story tree displays all the stories of the product. On the project level, the story tree displays only those stories that have been planned to that project from its parent product backlog.
The story tree view can be filtered based on story states, names, the backlogs they are in, and labels. To do this, click on the filter icon and select the filters you want to apply.
Stories that have no children are called leaf stories. Iterations can contain only leaf stories. Likewise, the project backlog view lists only the leaf stories included in the project.
If you’re wondering why terms such as ‘Epic’, ‘Feature’ and so on are missing, read Mike Cohn’s take on the matter. We agree with him.
Detailed prioritization of stories is done in list views. On the product level, there are no list views. On the product level, prioritization is about deciding in which projects and iterations the stories could be placed.
Projects have both the story tree view and a list view, called “Leaf stories”. Leaf stories are stories that have no children. The Leaf stories view allows you to prioritize the lowest level in rank order, estimate them in points, create tasks to them, assign responsibilities, filter them according to states, responsibles, and iterations, change the stories’ parents – and of course move the stories into and out of iterations.
You can move the stories to different iterations, products or projects from the edit icon (the overflow menu to the left-hand side of each row) or by drag & dropping them to the left-hand backlog tree.
Iteration list can only contain leaf stories. By opening the stories from the arrow sign, you can create tasks, and see and change the story’s parents.
My work is a view for personal work management. It consists of two tabs: stories and tasks.
Stories and tasks
A story or task is added to your My work view when you are set responsible for it, or when you drag & drop it from a backlog on top of the ‘My work’ text in the left menu. Stories and Tasks will also remain in your My work view until you manually remove it – even if you were no longer responsible for it. Also, unlike other list views in Agilefant, the story list may contain both leaf as well as non-leaf stories.
Stories and tasks which are done won’t disappear from My work automatically. This means that you can use this view to for example prepare for stand-ups; just leave what you got done since the last stand-up in the view, and then remove them when the stand-up is over.
You can remove stories and tasks by clicking the option in the overflow (three dots) menu on the right of each story or by multi-selecting the stories you want to remove and pressing the “remove from my work” button. The items removed from my work will not be deleted and can be found in the backlog (Product, Project, Iteration) where they reside.
By default, all users are responsible for the stories that they create and therefore they will also appear in my work even if the story is immediately assigned to someone else. You can change this setting in the administration menu (click on your name in the upper right corner), by selecting settings and in My settings untick the “auto assign myself to new stories” box.
You can prioritize the stories and tasks in My work as you wish; the changes done here do not affect the stories’ priorities in other views. The overflow (three dots) menu has an option to put the task or story to the top or to bottom, which can be convenient when prioritizing a long list of stories.
The simplest way for a single person to use Agilefant is to create a single product and some stories and do your prioritization using the stories list in the My work view.
In both an iteration and project views, you have some backlog specific settings available in the Details tab. You can for example show/hide story list columns, board columns, and choose what information is visible on a story card in the board view.
A timeline is a tab located in each backlog (if enabled in Account settings). It shows those stories from a backlog that has either a start date or planned start date and a due date. A timeline can also have milestones. One milestone can exist in one or multiple backlogs at the same time.
On a timeline, you can use the green ‘+’ and flag buttons to add stories and milestones, respectively, to a timeline. Alternative, you can double click the timeline – click on the timeline row twice to add milestones and stories row to add stories.
On a timeline, you can change the planned start date or a due date of a story by
– opening the story details view by clicking a story and changing the start date or due date,
– dragging the story item which will change both a planned start date and a due date,
– activating a story by clicking it (it will become yellow) and pulling either end of the story.
You can zoom the timeline using plus and minus icon buttons or by keeping alt key pressed while pressing up/down arrow keys or scrolling mouse wheel.
You can move right and left on a timeline by dragging the timeline element or by keeping alt key pressed while pressing left/right arrow keys.
Boards in the left hand menu are configurable views into stories in Agilefant. For example, if you’re working on a customer project, you might want to create a board to show an overview of how the high level goals or features of the project are progressing. Or, if you’re the product manager (or in Scrum terms, product owner) of a particular product, you might want to display the roadmap of your product:
As boards can only show existing stories, you need to have stories created in one or more backlogs. To get started, create a new board by clicking the ‘Create New’ (top-left) and hit ‘Board’. The columns and rows on a board are the criteria for choosing which stories the board displays. For a board to show anything, you must create at least a single column and set up its filter. Click ‘Add column’ to insert as many columns as you need. Then, to configure a column, do the following:
- Click the small gear icon in the top right corner of the column (hover the column name to get the icon visible).
- From the dialog, you can select backlogs, states, labels, responsibles, and/or due date which are used to filter out stories.
When you have added columns, you can also add a second dimension — rows — in the same way as you inserted columns. If you have both columns and rows, each cell displays stories, which are filtered through both column and row filters. By default, a board shows a lot of information regarding the stories. To make the board somewhat more compact, you can select what information to show. Go to Config and uncheck those story properties you want to hide. Additionally, you can rename columns and rows, which can be useful especially when there are multiple filters in a single column/row.
You can also use the board level filter in the Config tab to prefilter the stories through some filters, which would otherwise be repeated in all of the column and row filters.
You can move stories from a cell to cell using drag and drop. If the move is ambiguous, you will be asked to select properties to make them match filters.
In an iteration board, stories are divided into columns based on their state. In this board, stories can be moved horizontally from one state to another using drag and drop. You cannot yet prioritize stories in a single column as it would affect their order in the list view. Thus, prioritize stories in the list view and use the board to follow and change stories’ state.
From the iteration details tab, you can choose what story properties to show on a single story card, and show and hide columns of the board.
Accept stories to the board only from the selected backlogs. When you use this filter, then only data from the selected backlogs will be shown.
Story colors are used to show how a story/branch is progressing. There are four different states/colors: Gray – a state cannot be calculated or the traffic lights are off. Green – the story is going to be finished on time according to past velocity Yellow – the story is estimated to be within the margin on time but the story might not be finished on time. Red – the story is estimated not to be finished on time. Green/yellow/red colors can only be calculated for stories that have a due date and have child stories with story points. Otherwise, the color of a card is gray. Traffic lights work the best when you have a large story branch that has been worked on for several weeks as the color is calculated based on the historical velocity of the story. You can see the history data and the estimated velocity line by clicking on the story card and selecting the Burnup tab from the opened popup window.
The margin is used to adjust the threshold between different colors for the traffic lights. For example, you have 50 points left (not as done) in a story branch and a margin of 10%. Then the lower limit would be 45 points and the upper limit 55 points. Then based on the velocity the color will be: 1. More than 55 points would be done by the due date, the story is shown as green. 2. Between 45 and 55 points would be done by the due date, the story is shown as yellow. 3. Less than 45 points would be done by the due date, the story is shown as red.
Calculate velocity based on past x weeks
Used in calculating the traffic light’s color. The velocity is based on the historical data of the story branch. The velocity is calculated from the progression of the story (i.e. how many points have been done) in the past weeks.
Upper limit for stories per a cell
Used to limit the maximum amount of stories shown in a single cell. If you have lots of columns and rows, and this value is high, the user interface might become a bit slow. This will be improved at some point in the future.
Reporting is for generating spent effort reports of individuals and backlogs, and exporting data regarding stories and tasks into Excel.
Spent effort by backlog
You can calculate the aggregated effort spent by selected backlogs broken by each backlog in the given time period from selected users. To do this, select the users you want to see, then choose the timeframe, and backlogs from where the time entries are calculated. Then click ‘Spent effort by backlog’.
Spent effort by user
You can calculate the aggregated effort spent by selected users in the selected backlogs broken by each individual in the given time period. To do this, select the users you want to see, then choose the timeframe, and backlogs from where the time entries are calculated. Then click ‘Spent effort by user.
Export data to Excel
You can calculate aggregates of the time spent of defined people on defined products, projects and iteration on the defined timeframe and export the results into Excel for e.g. billing the customers. If you select only the product, all the projects and iterations under it will also be included. Selecting certain projects and iterations from the multi-select lists limits the calculation accordingly.
You can export nearly all of the data in Agilefant to Excel for different analysis purposes if you set the “Include stories and tasks with no spent effort” checkbox as checked. To get a better picture, look at the picture below.
In Agilefant, you can collect metrics of those projects, iterations, and stories into dashboards you are interested in and get a quick overview of those. For example, if you are a product owner and you have a project with three teams working on it, you can add the project and each of the teams’ iterations to a dashboard to get a quick overview of the progress. The picture below shows a project (1.0) and the ongoing iterations of the three teams working on it. You can drill down into the project and the iterations by clicking on the green links below the name of the widget.
As another example, the dashboard below shows how the four high level ‘epics’ of a project are progressing as a function of time compared to their planned scope. It has been created by adding the metrics widgets for the four parent stories representing the goals in question.
Lists in the left-hand menu are configurable list views to stories.
To create a new list, click on ‘Create new’ and ‘List.’ All the lists are listed in the left-hand side menu under ‘Lists’ in alphabetic order.
As a default, a list shows 100 last created stories. In the Config tab, you can rename the list, set the filters that are used to filter and show stories from all backlogs, and update the amount of shown stories in the list. For example, to list 50 latest documentation related stories that are not yet done, you could create a list called ‘Documentation’, set up the story filters to show all stories that has a label ‘Doc’ or ‘Documentation’ and which state is not ‘Done’ nor ‘Deferred’, and set the upper limit to 50. Currently, the upper limit is mandatory, so in order to show ‘all’ stories with given filter parameters, you should set the upper limit to something very large. However, the larger the upper limit is the longer it takes to fetch the stories.
Note that you can only see stories that you have access to based on access rights.
You cannot sort or prioritize stories in these lists. However, you can change the context of a story by drag-and-dropping it to another backlog in the left hand ‘Backlogs’ menu. Changing the context does not remove the story from the list unless you have configured the filter to list stories only from certain backlogs.
To remove a list, click on ‘Actions’ and ‘Delete list’. This will only delete the list, but the stories will remain in their backlogs.
Key Performance Indicators (KPIs)
In Agilefant, you can define KPIs to monitor key objectives of your projects.
First, as an admin user, go to Settings -> Account settings to create new KPIs if you haven’t created those yet. Click on the ‘Create KPI’ button. Provide a name and unit for the KPI and optionally a description and whether it’s cumulative.
When you have created KPIs, go to a project in where you want to monitor one or more of those KPIs. Open the ‘Details’ tab. You should see all the KPIs there.
For each KPI you want to monitor in that particular project, set an initial target for it, and then click on a green ‘Report’ button. If the button is gray, you haven’t set the initial target value yet.
In the Reporting dialog, you can log forecast and actual values for the KPI.
All the KPIs that have been reported to at least one forecasted or actual value, can be seen on the Burndown tab. Note that you can only show one KPI on the graph at a time.
On the ‘My settings’ tab, you can update your personal information such as your name, login name, default backlog and change your password.
The ‘Users’ tab lists all users in the account divided into enabled and disabled users. Via this page, you can edit the users’ settings and to enable/disable users.
For an admin user, the ‘Teams’ tab list all the teams she has in the account. Admin can create new teams, see who is in which teams and edit the composition of the teams. Non-admin users see only the teams they belong to.
The ‘Access rights’ tab shows all products and standalone iterations and lists all the teams which have access to the backlogs. This is the page where you can set the access rights.
The ‘Account settings’ tab contain account wide settings that affect every user.
Here you can enable Trello integration and set up IP filtering to limit access to specific IP addresses.
IP based filtering allows administrators to restrict the access to for regular (non-administrator) users to specific source networks. This could be usable for example in a scenario where the system should only be accessible from inside the corporate network, or via VPN. The source networks are given as a comma-separated list in CIDR format, e.g. 192.168.100.0/24, 192.168.1.0/24. This restriction affects neither administrators nor read-only iterations.
Stories Excel export
You can export all the stories in a backlog to Excel file using the Web query feature. First, enable Web queries in Account settings. Then go to the backlog (product, project or iteration) that you want to export. Go to the backlog’s details tab, where you will find Web query URL. You can either open the URL in browser, or export the data to Excel either with Microsoft Excel or LibreOffice.
Using JIRA with Agilefant
Agilefant’s JIRA integration enables you to do higher level planning and follow-up (e.g. Scaled Agile Framework, product roadmapping, portfolio management and program planning) in Agilefant while allowing individual teams to use JIRA.
Agilefant integrates both to cloud and server JIRA. The integration is designed to work with JIRA version 7 or higher, but also JIRA version 5.2 and higher probably work with Agilefant although these versions haven’t been tested so extensively.
You need to have an account in both JIRA and Agilefant to set-up the integration.
Note that if you are using a server version of JIRA, quite often existing firewall settings block traffic from Agilefant to your JIRA server. Our support can help in discussing with your firewall experts on what firewall rules to apply.
Setting up the JIRA-Agilefant integration
First, if you don’t have an Agilefant account, you can sign-up for free at app.agilefant.com.
In Agilefant you need to have at least one product and one project. Your JIRA project(s) will be linked to a project in Agilefant.
- Go to account settings (Settings -> Account settings)
- Enable JIRA integration
- Create JIRA integration
- Baseurl: JIRA instance e.g. “agilefant.atlassian.net” (or if using server JIRA give the ip address or the internal URL)
- JIRA project: The key for the JIRA project you want to link to Agilefant (to find a correct project key, go to JIRA and browse projects from the top menu bar)
- Agilefant project: Project in Agilefant you want to link to JIRA
- Give your JIRA credentials (to be able to import your tasks from JIRA and push stories from Agilefant to JIRA)
- Note! Give your JIRA username, not email! If you’re not sure what your JIRA username is, you can find it from your JIRA profile page.
- Adding more JIRA projects and JIRA instances:
- Add additional project mappings to be able to link stories to issues in multiple projects (give JIRA project key and Agilefant project same way as it was done in step 2.)
- You can link other JIRA instances by just creating a new JIRA integration
- Create a webhook:
- Go to JIRA administration (menu opens from the top right corner) -> System -> WebHooks
- Copy the callback URL https://app.agilefant.com/global/jira/webhook to the webhook settings
- Make sure you have selected the following issue related events: created, updated, deleted
- Configure custom fields
- Add custom field “Agilefant” for easy navigation (JIRA issues and epics will get the URL to the corresponding Agilefant stories)
- Create new custom field ( “Add custom field” button in JIRA Administration -> Issues -> Custom fields)
- Select URL Field
- Configure new Custom field with name “Agilefant” and a description (e.g., “Custom field for linking an issue/epic to an Agilefant’s story.”)
- Add it to project screens that you’re using in projects that will be linked to Agilefant (or just select all projects)
- Check that the new Custom field “Agilefant” is visible in the Custom fields list. At this point, you can start pushing stories to JIRA from Agilefant.
- Make sure you’ve enabled “Story Points” in the correct project screens (if you want Story points to be synchronized)
- Add custom field “Agilefant” for easy navigation (JIRA issues and epics will get the URL to the corresponding Agilefant stories)
Using the JIRA-Agilefant integration
In JIRA epics and issues form a two level hierarchy while in Agilefant you can have an unlimited hierarchy of stories. Therefore the epics and issues that teams are working on in JIRA should form the lowest levels of your story tree in Agilefant. This enables you to link JIRA epics to even larger entities in Agilefant. For instance in the case of Scaled Agile Framework (SAFe), it is typical that SAFe User stories link to JIRA issues, SAFe Features to JIRA epics, while larger SAFe entities like Capabilities and Portfolio Epics are not linked to JIRA and instead maintained only in Agilefant.
The properties linked between JIRA’s issues/epics and Agilefant’s stories are Summary (Name in Agilefant), Description, State, and Story Points. When an epic is linked to story in Agilefant, the epic’s issues will be child stories in Agilefant. If an issue has sub-tasks in JIRA, these sub-tasks will be child stories in Agilefant.
The five primary interactions between JIRA and Agilefant are as follows:
- An issue/epic is updated in JIRA => the corresponding story in Agilefant is updated automatically
- A story is updated in Agilefant => the corresponding issue/epic in JIRA is updated automatically
- When an Agilefant project and a JIRA project are linked the first time, you can, if you want, import the JIRA project’s all existing issues and epics to Agilefant (this is done in Agilefant settings)
- When a new issue or epic is created in JIRA, it will automatically be moved to Agilefant. Note that you might need to move the story in Agilefant to the correct location in the story tree (JIRA doesn’t know where that should be)
- New stories created in Agilefant need to be separately pushed to JIRA by right clicking in the story tree and selecting “Push to JIRA”. In the dialog that opens you can select to which JIRA project it will be pushed and whether it is an issue or an epic in JIRA. Stories that are already linked to JIRA will have in Agilefant the JIRA project key as a label.
- Updates from Agilefant to JIRA will fail if JIRA password contains umlauts.
Using Trello with Agilefant
Some teams like to use Trello, but there may be reasons to use Agilefant to get metrics of progress, link small tasks and stories to long-term plans, and track spent time.
Below we’ll explain how it can be set up, how it works in detail, as well as how to give us feedback. Also, check out what awesome things you can do when you combine the ease of Trello with the power of Agilefant.
How to set it up?
Sign up to get an Agilefant account, if you do not already have one.
Then, you need an admin user to enable the integration from Administration → Account settings → Trello integration.
The integration itself works by linking iterations in Agilefant to Trello boards.
First, you must create an iteration. If you’re interested in sprint metrics – or want to get started as quickly as possible, create a standalone iteration.
If you want to group Trello cards to form bigger entities and do roadmapping, create a Product and use Standalone iterations to make it go forward.
If you want to monitor project/release progress or do portfolio management, create one or more products, and then projects and iterations under them.
While Agilefant’s user guide will help you with the details related to the above steps, if you feel like you’d like to have live assistance, simply reach us out in chat or send an email to email@example.com!
How does it work?
Linking an iteration in Agilefant to a Trello board is done from the Details tab of the iteration.
When the linking is done, the stories in the Agilefant iteration will appear on the Trello Board – and/or the cards from the Trello Board will appear in Agilefant.
When you in Agilefant move a story into an iteration which is linked to Trello, it will appear on the board. When you move it away from an iteration, it will be archived on the board.
You can create new stories/cards both in Agilefant and in Trello.
The table below shows shows how concepts in Agilefant are linked to the concepts in Trello.
|Iteration||Board||You can also unlink boards from iterations; if you unlink and then link again, the cards / stories will be duplicated in both of the tools.|
|Story state||List||Mapping story states to Lists is done when you do the link.|
|Story points||(1) card name||If a Trello card’s name begins with an integer in parenthesis, Agilefant parses it as the story points.|
|Task||Checklist item||You can mark a task done by checking the checkbox in Trello. Otherwise, the tasks will be ‘Not started’ in Agilefant.|
|Description||Description||If you link a board with existing cards, a hyperlink to the story in Agilefant will be appended into the card’s description.|
|Comments||Comments||You can do time tracking by entering spent effort as comments in the following format: [spent:XXX] – where XXX is the number of minutes you’ve worked on the card; for example, 180. Note: Editing or deleting spent time entries afterwards is not possible from Trello; you have to do it in Agilefant.|
|User||Board member||Users in Agilefant can be mapped to Trello users. In order to do that, the Trello user must be a member of a linked board. Responsibles in Agilefant which do not have a corresponding Trello board member will show up in red.|
For all of the linked attributes (except spent time entries which were directly from Trello), Trello will act as the master. After the link is done, if you try to edit the attribute in Agilefant, it will direct you to the respective Trello card and ask that you’ll do the changes there.
You can also unlink an iteration from a Trello board. The stories in the iteration will remain in the iteration, and the cards on the board will remain there as well. However, changes in one tool will no longer be reflected in the other.
Mapping Agilefant’s story states to Trello Lists
The first time you link a Trello Board to an iteration in Agilefant, you have to map the lists on the Trello board to the story states in Agilefant. Currently, stories in Agilefant can have one from six distinct states:
Only the Done and Deferred states have metrics-wise (and other) functionality added to them.
Currently, it is not possible to have a Trello list which would not be synced to Agilefant at all (this will be changed in the very near future).
How to give us feedback?
We will be working to take the marriage of Agilefant and Trello where you want it to go.
There’s a Trello board, linked into an Agilefant iteration, and you can vote which steps we should take next, as well as comment on them
The board also keeps track of all the open bugs and issues we are currently aware of.
If you want something added to the board – or otherwise want to talk to us – reach out in chat, or email us at firstname.lastname@example.org.
Using Deveo with Agilefant
Agilefant is now fully integrated with Deveo. For developers, it is now much easier and more efficient to finish your individual work whilst ensuring that all works aligned with other parts of your projects. Deveo has a post-commit hook for referencing Agilefant stories from code commits that include the story id in the commit message. If you are still not sure what Deveo is, Deveo is a repository management platform that helps you manage all your source code and binary files with one tool. Deveo is designed and built for the developers in mind; the tool offers a more seamless way for developers to manage their work progress and files.
If you want to know more about – or otherwise want to talk to us – reach out in chat, or email us at email@example.com.
Does Agilefant support Kanban?
You can view iterations either as a list or a board, however you wish. You can also create custom boards to visualize the stories you are interested in on a board-like view. Agilefant does not yet have explicit work-in-progress limits.
Does Agilefant support Scrum?
Yes! Agilefant’s basic model is based on Scrum. Agilefant offers sprint burndown and project burnup charts, splitting stories into tasks, task estimation, story points and much more.
Does Agilefant support SAFe (Scaled Agile Framework)?
Yes – and here’s a longer explanation on how to do it!
The Scaled Agile Framework (SAFe) refers to Dean Leffingwell‘s model for scaling agile software development. During the 2000s, Aalto University’s Software Process Research Group – who created the initial version(s) of Agilefant – independently (as documented in our published research) ended up with a model very similar to that of Dean Leffingwell’s SAFe.
Consequently, Agilefant’s conceptual model is in many ways the same as that of SAFe. Actually, Agilefant supports SAFe way better than many of the tools out there who claim to do so. What you need for SAFe to properly work is an infinite story hierarchy – not three or four or however many levels SAFe may come up with – and this is provided by only a couple of tools out there.
Agilefant currently misses explicit functionality to model strategic themes, but this can be worked around using labels. Full support for strategic themes them is also on the roadmap.
Does Agilefant work in a traditional and non-software related project management?
Basically, agile methods are suited to manage any complex collaborative expert work when detailed planning right at the beginning is not feasible. We see no reason Agilefant wouldn’t suit such situations, software or non-software.
There are many non-software organizations worldwide using Agilefant for managing their work. Agilefant has also been successfully used to manage multi-year industry/Tekes/university research projects, where the involved university staff members have a diverse ‘portfolio’ of efforts they are attending to (e.g., publishing, industry collaboration, teaching, soliciting more funding, other post-graduate studies etc.).
Of course, the terminology so far remains agile specific, which originates from the software development scene. However, little of this jargon (stories, tasks, projects, products, iterations/sprints) really is software specific in itself – and in fact, there are a number of white papers and blog posts of agile being successfully used to manage non-software efforts.
Does Agilefant support bug / issue tracking?
There is no direct functionality for bug tracking in Agilefant. However, you can keep bugs as stories hanging around in the backlogs just like other stories. You can denote them with the label “Bug” and then use filters to find the bugs.
Also, if you’re using the story tree to structure your product’s stories, it might be a good idea to add bugs as child stories to already done stories. How we do bug tracking is simply by keeping the bugs in a special, never-ending iteration, and labeling them with “BUG” as suggested above.
While we are not planning to do comprehensive bug tracking features in the near future – as we so far see little point in doing so – doing a plugin for the most popular open source bug tracker (that might be Redmine, Mantis or Bugzilla – if you have something else in mind, do make a suggestion!) is something we could do.
And, you can always sponsor the development of a plugin to your favorite bug tracker!