There are three kinds of backlogs in Agilefant: Products, Projects and Iterations. The product backlog contains “everything” that may possibly 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 interrelationship among these backlogs are illustrated below:
Product is the generic term used for something the organization is developing such as a piece of software or service. 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 has access to that product. Otherwise, non admin users cannot see the created product. You can change this later from Administration -> Access rights. In Agilefant you can have as many products as you want.
Products are developed in projects. You can think of projects as ’major releases’ or important milestones (although Agilefant doesn’t restrict you from releasing once per each iteration, or per story, should you wish) – 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 in terms of progress versus a deadline, and make that as your project.
Projects can be created from the Create new menu. 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 red 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 grey 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 burnup graph by defining how it should point unestimated stories — you can for example define that each story is size of one story point. This video has more information on how to read the burn-up chart.
An iteration is a time-boxed period of time 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 parallel iterations for a single project – for example, when multiple teams are working for 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:
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; and if the parent is on the product level, the story parent-child relationship is broken only if the target project is in a completely different project.
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 a 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:
To edit the name of a backlog, 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.
Open the product/project/iteration in question. Click on ‘Actions’ dropdown on the top of the page, and choose ‘Delete’.
Currently iterations are 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 completely different project.
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 a read-only access to the iteration.
You can set the default backlog for users on the same page where you edit the user’s info. For youself, go to Administration and My Settings and select the Default backlog. For another user, go to Administration and Teams. Then choose the user and click on Edit. Then select the Default backlog for her.
When you’re creating new work items (that is, stories or tasks) in an iteration, project or product, the context for the new item is obvious. That is, the new item will appear to that iteration, project or product you are in.
However, when you are creating a new item in the My Work view, or in some cases via the Create new menu, there’s no way for Agilefant to “guess” where you would want the new item to go.
And sometimes, you just want to quickly write down something 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. This is when the default backlog is especially useful.
In Agilefant, each user can set their own default backlog. Currently, the default backlog must either be a regular 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 really 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.
In newly created Cloud accounts, the pre-created user’s default backlog is the ongoing iteration of the example product.
You can export iterations as .xls. This can be done by clicking the ‘Export’ link under ‘Actions’ button in iteration view.
You can always look at the project burn-up graph. The burn-up should show the history of the story point sum of all stories under the release, as well as the completed ones.
Importing backlogs is not yet possible – but if you are switching to the Cloud version, you can ask us to help you out.
Currently you cannot copy projects nor iterations, but only stories.
A story is a piece of work that needs to be done. Agilefant only calls stories, no matter whether they have child stories or not or how big they are, simply as Stories.
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. We haven’t dissociated epics, features and user stories from each other. We have made it simple and call them all as Stories. Stories can be anything from business goals, customer requests and features to small issue descriptions. The only exception is tasks, which are used to describe the work needed to get the story done or some small tasks such as meeting or phone call.
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. Thus, if you wish to prioritize your stories but don’t want to create projects or iterations, just use the story tree view! 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 to 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.
The relative size of stories is estimated in story points. 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 the many options, but it works fine. 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, lets 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 also have pre-defined states. You can think about their meaning as follows: The following states have ‘special effects’:
Done and Deferred tasks/stories are also excluded from the ‘My Work’ view but are normally visible in the backlog. The following states have no ‘special effects’:
Sometimes we have been asked if states can be customized. Currently you can't. However, customized states are on the 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.
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 two places: from the ‘Story Info’ dialog (available in the story tree and the project planning views) and from the list views. 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.
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 to select 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.
You can upload attachments to stories. In a story list view, expand the story and drop the files you want to attach onto the drop area, or alternatively click it and choose files. In a ‘Story info’ dialog, attachments lie in the Description tab. You can also attach files and images via the description editor. Click either ‘Upload file’ or ‘Insert image’ button and choose files.
You can also use the description field to upload attachments (currently only to stories). Click the description field to activate it and click either ‘Upload file’ or ‘Insert image’ button and choose the attachments.
If you want to upload documents to tasks or backlogs, we suggest you to 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.
Each organization has 1GB space for attachments and the maximum size of a single file is 10MB.
You can create stories directly to a backlog from the blue ‘Create story’ button located on the top of the story list and story tree, and from the ‘Create new’ menu.
Delete a story via right hand side pencil icon (in a list view) and select 'Delete'. In the tree view, click on the story to open the story info dialog and click 'Delete'.
There’s no Undo currently, but if you’ve deleted (or otherwise lost) something important and are 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 retreived, and a time, when the list things for sure were still there.
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 prioritisation 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 final place to set priorities for tasks and stories – although this affects the user doing the “prioritisation” is in the task and story queues of the My Work tab. This kind of “prioritisation” 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 prioritised by drag-and-dropping them to the correct order (most important at the top). On the product level, ‘prioritisation’ of leaf stories is done by moving the story to the correct project and / or iteration. Parent stories (= stories with children) can’t be prioritised, as this would make little sense – for example, “are all child stories of Feature X more important than all child stories of Feature Y”.
In Agilefant, there are many ways to create tasks inside stories:
You can also move an existing task onto a story. In a list view, expand the story to where you want to move the task. Then, drag & drop a task onto the story.
The recommended way is to use the ‘Extract unfinished’ action, which can be found by clicking on the pen icon to the right of the story’s row. This creates a copy of the story in question, and moves all tasks which are not done to the newly created story. The done tasks, and all effort spent will remain in the original story.
Another option is to use the ‘Copy story’ feature (see edit button in iteration view). 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.
There are at least two alternatives:
There are several ways to move stories and tasks from one backlog to another in Agilefant:
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.
You can move stories both in a story tree and a list view.
From the story tree:
From the list view:
In iteration view, there is an Copy functionality in the pencil 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 otherwise have no effect. 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.
Tasks can be created in all the those views that contain a list of stories: the My Work view, the Iteration view and the Project leaf stories view. To create tasks, click on the plus (+) sign to open a story – there you will find the Create task button:
You can also add tasks to stories in the story tree. Just click the story and select the Tasks tab from the dialog. This is also the place where you can access tasks that are not in any iteration.
You can edit tasks of stories you are responsible for in all views you have access to them: for example, an iteration, a project, a product, or the my work view. If you are responsible for 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.
In order to do this, tasks have to be in the same iteration. Then expand the story to which you want to move tasks, and just drag & drop tasks onto the task list.
If the stories are in the same sprint, simply open the story (so that you see its tasks) you wish to move the task from, and drag & drop it on top of the target story.
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.
Lets take an example: If you originally estimate the task to be 10h (original estimate = the first estimated effort left = 10hrs) and after you’ve spent 8hrs, you still think that it’ll take 8hrs to finish, you log 8 more hours to spent and 8hrs to Left. Later, you work 5 hrs and get the task done. Then you put 5 more hours to Spent so you have spent total 13hrs on that task. Now you should also set Left to zero (because task is finished).
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 link. This is located in the upper right side of the page.
You can log effort for stories and tasks from many places; the picture below highlights all the places that are available in the list views (project leaf stories, iterations, my work):
In the story tree and the project planning views, click on the story and the info dialog opens; the spent effort link is on the bottom of the dialog:
If the time from your last logged effort entry is less than 8 hours, re-fills the field with the difference. Thus, Agilefant makes it easy to log effort as you go. From ‘My work’, you can inspect the daily hours spent. Click on a day’s total hours to see a detailed list of the effort entries.
Users can be set as responsible for stories and tasks. This can be used to 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 for 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 but this is not used anywhere.
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, editing other users’ info, setting access rights, editing teams, exporting 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.
To invite a new user, click top left ‘Create new’ and then ‘User’. An automatically generated password is sent to the new user’s email 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.
Currently, you can’t delete users but only disable them. You will not be billed for disabled users.
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 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.
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. Basicly, 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 have full access to their backlogs.
Access rights are managed in Access rights under Administration menu and they work in a following way:
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 epics and features. 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.
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 think so, too.
Prioritisation of stories is done in list views. Note, that on the product level, there are no list views; rather prioritisation on the product level is more coarse-grained, and concerned 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 prioritise 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 pen 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 plus (+) sign, you can create tasks, and see and change the story’s parents.
My work is a view for personal work management. In addition to the graphs which show the amount of story points and hours in stories and tasks assigned to the user, it contains three lists: a task queue, a story queue, and a tasks without story queue.
The task queue shows those tasks you have (or somebody else has) appended to your task queue. You can use this list to make yourself a short-term plan of what you intend to tackle in the very near future. You can also use the task queue to keep track of what you have done for preparing for the next stand-up meeting - mark those tasks you have done as ‘Ready’, and once the stand-up is over, the tasks disappear from the list when you mark them as done. You can prioritize the tasks in your task queue as you wish; the changes done here do not affect the tasks’ priorities in other views.
The story queue shows all those stories you are responsible for or which have tasks you are responsible for, and collects them from all projects and iterations whose start date is in the past into a single list. Thus, the story queue may, unlike other list views in Agilefant, contain both leaf as well as non-leaf stories. For example, the story queue may contain both a parent story and its children, if you are responsible for them. You can prioritize the stories in your story queue as you wish; the changes done here do not affect the stories’ priorities in other views. The simplest way for a single person to use Agilefant is to create a single product and some some stories, and do your prioritization using the story queue in the My work view.
This lists collects all the tasks without stories you are responsible for from all iterations whose start date is in the past into a single list. Tasks without stories cannot be prioritized in this view. They are listed according to the iteration or project they belong to. Unlike the iteration and the project list views, daily work may show stories which have children, if you are responsible for the parent story itself.
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. See the image below.
You can create a board by clicking the ‘Create New’ (top-left) and then choosing ‘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. Click ‘Add column’ to insert as many columns as you need. You can currently choose which stories are shown on a board based on the following properties:
To configure a column or a row, do the following:
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.
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.
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.
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.
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.
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 in the upcoming releases.)
Reporting page is for generating spent effort reports of individuals and backlogs, and exporting data regarding stories and tasks into Excel.
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’.
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.
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, stories and user workloads into dashboards you are interested in and get a quick overviews 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 blue links at the top of the metric widgets.
As another example, the dashboard below shows how the four high level goals of a project are progressing as 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.
My settings allow you to update you personal information such as name, login name, default backlog and change your password.
Users page list 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.
Teams page list all the teams you have in the account. You can create new teams, see who is in which teams and edit the composition of the teams.
Access rights page shows all products and standalone iterations and list all the teams which have access to the backlogs. This is the page where you can set the access rights.
Account settings contain account wide settings.
IP based filtering allows administrator 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 affect neither administrators nor read-only iterations.
You can create a zipped dump of the database of your Agilefant instance here. This is pretty handy if you want to create manual backups of your database or search for something.
If you want to move data from your own Agilefant server to the cloud, contact us by email and we can do it for you.
Experimental features contain stuff that we are developing out of curiosity, or as a prototype as per request of a certain hosted organization. They may or may not become an actual part of Agilefant. Think of them as ‘hidden Google Labs’. By default, experimental features shown only to those organizations involved in their development.
Subscription page contains information about your subscription. You can subscribe more seats or cancel your subscription here.
Yes! Each iteration has a board that allows you to do Kanban in Agilefant.
Yes! Agilefant has a full support for Scrum. Agilefant offers sprint burndown and project burnup charts, splitting stories into tasks, task estimation, story points and much more.
Yes! 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.
As a result, Agilefant’s conceptual model is in many ways the same as that of SAFe: Agilefant’s Product and Project correspond to SAFe’s Agile Release Train and Program, respectively. Actually, Agilefant supports SAFe way better than many of the tools who claim to do so. What you need for SAFe to properly work is an infinite story hierarchy – not three levels – and this is provided by only a couple of tools out there.
Agilefant currently misses explicit functionality to deal with investment themes and the portfolio epic kanban, but these limitations can be worked around, and full support for them is in the roadmap.
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.
Agilefant has 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.). Additionally, there are several non-software organizations worldwide using Agilefant for managing their work.
Of course, the jargon is remains agile specific, which in turn happens to originate 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.
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 a Jira integration is also something which will happen during this year.
And, you can always sponsor the development of a plugin to your favourite bug tracker!