As Agilefant is quite rich in features, this guide covers only the most important concepts and views of the Cloud version. There is also a separate guide for the mobile app. If you’re looking for an explanation for a specific concept or feature, use the browser’s search (Ctrl-F) to find the keyword you need. There’s also plenty of more detail on some features the frequently asked questions page – so take a look at it if something isn’t explained here! You can also chat with us or email firstname.lastname@example.org.
- Accounts, users, teams and access rights
- Concepts in Agilefant: Stories, Tasks, Backlogs, Responsibilities, Spent effort, Labels, Dependencies, and Attachments
- Story tree
- List views: leaf stories, iteration (= sprint), my work
Getting an account
Sign up by providing your email and an account name, and and you’ll get a fresh Agilefant account containing some example data.
Changing your password
To change your password, click your name in the top right corner of the page:
This will take you to your user page. The Change password button is at the bottom of the page. If you lose your password, request a new one via this link: Forgot a password? If you are unable to reset the password, email email@example.com and tell us your email address and the account name.
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. Users’ login names must be unique in the Cloud, 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 – we can do it for you. Note, that in the open source version, users cannot currently be invited to Agilefant, but you have to create the user and send correct person the credentials. Random.org is a good site for generating random passwords. You should define at least one team each newly created user is member of. Access rights are based on teams, so with no teams, the user cannot get access to anything.
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 (see below).
Agilefant provides ways to limit access of products and standalone iterations. You can define access rights based on teams basis. This is useful when you want to limit the visibility of certain products or standalone iterations. This can be done in Access rights under Administration.
- Admin users may do anything, non-admin users are limited to the products and iterations their teams have access to
- Non-admin users may create new products that their teams have access to and add new users to their teams
- 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.
Concepts in Agilefant
Agilefant’s main concepts – Stories, Tasks, Backlogs, Responsibilities, Spent effort, Labels and Dependencies - are explained below. For an overview, be sure to look at the conceptual model tutorial video! In addition, we briefly discuss how the access rights work, and how you can export your database.
A story is a piece of work that needs to be done. Stories can be created directly to a product, project or iteration, or from the Create new menu. Look up from Wikipedia a longer definition of the concept of user stories.
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 (as well as tasks) also 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.
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’:
- 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.
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.
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. This can be the case if for example something is so small that a new story is not needed. 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. Tasks are estimated in man-hours. In Agilefant, the first estimate for a task becomes its “original estimate”. Original estimates affect the iteration burndown, but otherwise have no effect. You can reset the original estimate from the Edit button of 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.
There are three kinds of backlogs in Agilefant: Products, Projects and Iterations.
Think of backlogs as containers of stories:
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.
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 also think of projects as ‘major releases’ or important milestones. 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. However, there can be parallel projects under a single product. 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 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. 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.
For more on how Agilefant calculates the iteration burndown, read the related FAQ entry. For more information on the concept itself, look up (for example) the related Wikipedia entry, or watch this video.
Itertions 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 can include stories from multiple products and projects. Standalone iterations are created like regular iterations, with the exception that the ‘parent project’ in the creation dialog is simply left empty. For further info regarding standalone iterations, check out the related FAQ entry.
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 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.
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.
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. On a story list view, expand the story and drop files you want to attach onto the drop area, or alternatively click it and choose files. On a story 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.
Each organization has 1GB space for attachments and the maximum size of a single file is 10MB.
Database export / Backups
You can create a zipped dump of the database of your Agilefant instance. This is pretty handy if you want to create manual backups of your database, or search for something. To do this, you need to log in as an Administrator and go to Database export (under Administration) and click ‘Export database’.
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 in the project, and their parents. 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 for 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 On the iteration level, only the list view exists. 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: the task queue, the story queue, and a list of tasks without stories.
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.
Tasks without stories
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 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:
- story states
- story labels
To configure a column or a row, do the following:
- Click the small gear icon in the top right corner of the column.
- From the dialog, you can select backlogs, states and/or labels 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.
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. You can read more about the burnup chart at here.
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 in the upcoming releases.)
On this tab you can create timesheet reports and export the data regarding stories and tasks into Excel.
You can calculate aggregates of the time spent of defined people on defined products, projects and iteration, 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 (see picture above – it’s highlighted in red). To get a better picture, look at the picture below. You can also download the entire .xls download the entire .xls of the example data in a freshly created account as exported into Excel.
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.