User Guide
The work-in-progress user guide to Agilefant 2.0 can be found here. It is freely editable, so you can easily contribute to it by either asking questions and waiting for them to get answered, or by writing how stuff works. So far we are keeping the doc in a FAQ-format.
The recommended way to ask a how-to question is to post it in the 2.0 user guide. Technical questions (trouble with installation, bugs, etc.) are to be asked on our forum.
Also, you may be interested in seeing how HardSoft Inc. (a pseudonym) is using Agilefant (the 1.6.2 version, mind you)!
Finally, at least for the time being, below is also some stuff related to version 1.6.2. Some of it is in HardSoft's guidelines, some is not.
How to do contracts that support Agile software development?
This working group is thinking about it. Check it out, and let us know if you find more material on the subject.
What, there's no user rights mgmt in Agilefant?
The question about restricting user access to some parts of system is raised every now and then. So far we have found other things more valuable to implement, and are somewhat skeptical whether restricting user access would even be aligned with agile principles. We posit that every employee is trusted and if this trust is broken it is an organizational problem that shouldn't be tackled with a tool in the first place.
While there are some business situations where restricting users access to some parts of the systems may be justified, for example by giving progress reports to customers, we have so far been able work around the actual need to let outside people into the Agilefant instance by providing PDF-prints of the sprint pages in question.
Still, below are our current thoughts on how adding user rights mgmt to Agilefant should be approached.
User rights affect almost everything in the system, so the simplest approach that does the trick should be taken. Even the simplest specification tends to expand rapidly. Below are our present thoughts in a step-by-step manner. Here goes...
- There should be two levels of access rights: unrestricted ( the user is allowed to do anything - this is the current situation in 1.5 for all users) and restricted (the user can see only those projects she is assigned to - see step 3 below).
- Projects can be set as public (default) or classified
- Restricted users see all public projects and those classified projects they have been assigned to; Things to be considered:
- Restricted users shouldn't see the Dev Portfolio page or private projects should be hidden from there
- Restricted users still might have Backlog Items assigned to them in private projects they haven't been assigned to. Thus such items and projects/iterations should be hidden from the Daily Work page
- Restricted users access to Timesheets should also be thought. So that they cannot generate reports for private projects they are not assigned to
- The Roadmap in Product page should be modified so that information of private projects isn't shown to restricted users
- Restricted users must not be able to create new users
We have not yet examined what this means source-code-wise. But if the above specification would solve your problem, you should start by examining the Spring Security Framework which is the authentication mechanism used in the Agilefant. When you hit some specific issues please feel free to ask us.
Iteration goal vs. backlog item priority?
"Since in Scrum the priority is solely the attribute of stories committed to in an iteration (i.e. Iteration Goals in Agilefant), why do the tasks (i.e. lteration level backlog items) have priorities as well?"
See HardSoft Inc.'s guidelines.
How to see what the team has done since the last daily stand-up?
See HardSoft Inc.'s guidelines.
How to mark those things you plan to do before the next daily stand-up?
See HardSoft Inc.'s guidelines.
Is the effort left for and item updated automatically when I log hours to it?
No, because tracking progress is a fundamentally different thing than recording spent effort (for whatever purpose). For a more detailed explanation, see the question on Effort estimates vs. logging effort spent below as well as See HardSoft Inc.'s guidelines.
When I update the estimated effort left, does it always go to the current date?
"Sometimes a person is not able to update the effort left on the same day. The velocity graph then remains horizontal for the days for which effort left is not entered and when accumulated effort is entered, it shows a sharp dip."
That's right. There's currently no way to adjust the date afterwards (like you can for logging effort spent). Should there be many requests for this for valid reasons, we will make the change. But so far, we've seen this as a feature that encourages regular progress updates.
We recommend you update the effort left (as well as log effort spent) as you go along, right before your daily meetings at the latest.
Or what do you think? In what kinds of situations it is beneficial and really useful to allow for 'fixing' the burndown graph afterwards? I don't deny that there may be such situations - let us know!
We want to attach files (i.e. an UML diagram) to backlog items. How to do it?
Attaching files to work items is a common feature in these kinds of tools, but so far we think that the following workaround will do the job just as well:
Put the attachment to wiki (etc.), and
a) add a hyperlink to it to the item's description
b) put a hyperlink to the backlog item in the document in question or on the wiki page which it resides
In Agilefant 1.5.3, which we are testing right now, there will be a new feature that makes it easy to hyperlink to individual backlog items.
We want to use story points, but Agilefant has only hour-based estimates?
Unfortunately, only hour-based estimates are currently available in Agilefant. However, the possibility to use points is in the roadmap with a relatively high priority (not in the *immediate* future though, we are currently working on hierarchical backlog items).
We suggest you do the following (we actually do this ourselves): estimate everything in minutes - and use them like you would use points.
In iterations, we create iteration goals for the backlog items (one for each) that are selected for the iteration, and then create backlog items to denote the 'tasks' for those. These are then estimated in hours.
A bit of a workaround, but does the job. In the future, things will change for the better regarding this issue.
How to handle chopping big user stories into smaller (a.k.a. hierarchical backlog items)?
"How to record User Stories in the system? Some of our BLIs are small User Stories. But a bigger User Story would be too big for a BLI. We thought maybe we could put the User Story as an Iteration Goal. This also looks good from my managers' point of view, as then she doesn't have to worry about the individual BLIs (which sometimes are a bit technical for her), but can see a summary of how we are getting on with the main User Stories. However, this is a bit complicated because you cannot add an iteration goal until after you add an Iteration"
This question is actually at the heart of the big thing we are taking on right now - both in terms of our research project (www.agilefant.org/atmanblog) as well as Agilefant.
In the future, Agilefant will have hierarchical backlog items: with these, it will be easy to have the big user stories in the product backlog, which in turn can be composed of smaller user stories. All backlog items will by default estimated with story points.
Then, when planning a sprint, you take the most important user stories (if all are big, you should chop them smaller!), put them into a sprint and start chopping them them down as tasks (which are estimated in hours) until you have your velocity full of stuff to do for the next sprint. If all of the items did not fit, you should put them back in the product backlog.
This way, from any task, you could see the backlog item (i.e. story) it relates to, follow the trail on to the original big backlog item/story, all the way up to the 'biggest user stories' - which should represent your organization's business level goals and objectives.
But as said, this is what we are working on now, and it will take some time before we get there!
In the meanwhile, this is a suggestion of how you do this in Agilefant 1.5.1 (if you have an older version, please upgrade - 1.5.1 contains several handy improvements to theme handling). This is a bit of a workaround, but will accomplish roughly what hierarchical backlog items would.
- keep the big items in the product backlog
- have one theme to represent each big item
- when planning a project, attach the big-item-theme(s) to the project, and plan how you are going to divide your time into advancing each
- on the project level, create items to detail various parts of the big item until you have your velocity full for the project; tag them with the respective 'big-item-themes'
- when planning an iteration, create an iteration goal for each 'project-level' item you are taking on in that iteration
- create items that need to be done so that the iteration goals are achieved; tag them with the respective big-item-themes
- if you want, you can simulate story points on the product and project levels by using minutes instead of hours (e.g. 1min = 1 story point, and so on); in iterations, you should have your estimates in hours, however!
In a near-future-release (probably some time in Nov), there will be a feature that makes it easier to manually (using the description fields) hyperlink backlog items, themes, and iteration goals. This will make some things a bit easier in terms of simulating hierarchical backlog items.
Tell us if this helped, ask any clarification questions you might have, and let us know if you found alternative solutions to tackling your question!!
Effort estimates vs. logging effort spent
Question: "I am not sure how to record how much time I have actually spent on a backlog item so far. I can change the 'Effort Left' but what if the original estimate was wrong? For example, if the original estimate was 7h and I spent 3h working on it but only have 2h to do, if I change the 'effort left to 2, it looks like I did 5 hours work when I haven't."
The dilemma you are facing is because of the fundamental incompatibility between tracking progress (= estimating how much there is work left) and recording spent effort (for whatever purpose, for example billing the customer). And a common misconception we have found in organizations is to view these two as directly linked, when in reality, they aren't.
The right thing to do in this case is probably to enable the Timesheets functionality from the Admin tab (if you haven't already done so), log the effort spent to the backlog item (or the project, if there's no need to account for costs on a per-backlog-item basis), and estimate effort left independently of what you have spent. And, you can always reset the original estimate if needed, for example, if the specs of the item changes so that it is much larger or smaller than thought of when the initial estimate was given.
However, the idea is NOT to make the time spent match the estimated hours! Like said, estimated effort left is for tracking progress, and recording spent effort is for billing (or cost accounting or whatever), and these usually have very different concerns.
More on (agile) software development and time tracking in e.g. Jeff Sutherland's blog (article 1, article 2) Evanetics.com, ... . Note however, that these articles are opinions by consultants' (experienced ones, though), not science.
How to denote the customer(s) that request certain backlog items?
Request: "It would be useful to be able to record the 'customer' responsible for a BLI. If an item is raised, and we put it in a future version, it would be useful to easily see items for that 'customer' so we can easily find it again and tell them when it is scheduled."
Currently, you can do this using Themes (see below for more on themes). Just create a Theme per customer, and add them to the BLIs you wish. If you attach that theme to a project or an iteration, they even show in the product roadmap on the product page.
What are the warning signs (alerts) that occasionally show in the Daily work view?
Currently, Agilefant presents warning signs in the Daily work view in two cases
- When a user has, in a project or in an iteration been assigned backlog items that have not yet been estimated in terms of effort. The warning signs point out that calculated Load is less that what it would be should these remaining items be estimated as well
- When a user is responsible for one or more backlog items in an iteration or a project that he is not assigned to. The warning signs point out that the user is responsible for something he should not be working on
What are iteration goals and how to use them?
While Scrum remains vague on Iteration goals vs. Committed backlog items (the most common answer we get when asking this question is something along the lines of "Huh? ... I dunno... I suppose getting the committed backlog items done is the sprint goal"), we have found it useful to abstract one or more iteration goals per sprint to guide the development team.
Iteration goals should be used to provide tangible, Business goal related objectives for the Iteration that go beyond or summarize the individual Backlog items selected for the Iteration.
For more on iteration goals, read:
http://www.agilefant.org/atmanblog/wp-content/uploads/2008/02/sdg01-vahaniitty.pdf
and
http://www.ibm.com/developerworks/rational/library/1742.html
(search for 'iteration goal')
Should we postpone the iteration deadline if there's nothing yet ready to demo?
Question: "I've heard that an iteration should have a specific size (e.g. 2 weeks) and at the end of each iteration you review what has been done with the users. What if we don't complete any backlog items? Should we postpone the iteration deadline, or move everything to the next iteration?"
Your question is actually addressing what is probably the heart of Agile and Lean development.
It sounds like you have a problem with a) knowing your velocity (i.e. understanding what you can realistically get done in a given timeframe) and thus taking on too much work, b) not chopping the backlog items small enough before the start of an iteration and c) working on too many different things in parallel.
The idea should be to maximise throughput (that is, the number of completed, demonstrable items - no matter how small) and forget about worrying about optimizing resource utilization - it should take care of itself.
So we recommend that you should not postpone the iteration deadline. Instead, admit that you had taken too much work on, agree with your customer on what the most important items from the iteration are, move them to the next iteration, and put the rest back in the product or project backlog to wait for the next one. Then, focus on getting the important items done, possibly even one at a time (this is called 'one piece flow' - do some Googling as well), so that even if you can't complete them all, you can still release & demo the ones that ARE done.
Over time, you'll learn what your actual velocity is (in other words, how much 'estimated hours' you can on the average get to zero in an average iteration.
There's a lot of reading you can do on this subject. You might want to start with Poppendiecks' writings, but there's plenty of material available for answering your question.
How do the Load meter thresholds work?
The load meter thresholds under the Administration tab can be used to set what the Load meter in the Daily work view visualises as low, optimal, high and very high levels of load compared to that user's current capacity (which can also be set under the Administration tab.
For example, in our team we have at the time of writing this set them as follows based on our experience on what's realistic & reasonable in our context:
| Minimum |
0% |
| Optimal Low |
60% |
| Optimal High |
85% |
| Critical |
95% |
| Maximum |
120% |
Thus, the meter begins at zero, denotes loads between 0 and 60% of total capacity as 'low', 60-85% as 'optimal', 85-95% as 'high', 95-120% as 'far too high', and stops the dial at 120%.
What are Themes and how to use them?
The following is adapted from Scrumworks Pro's User guide (thanks to Danube!); the same goes for Agilefant as well:
Themes are the primary mechanism for categorizing Backlog Items. Rather then use a hierarchical system like folders for categorizing the Product Backlog directly, Themes provide a means to associate specific keywords to Backlog Items. Themes group all items together that have been tagged with a specific Theme. And unlike a folder system, you can add as many Themes to a Backlog Item as desired.
Hierarchical categorization does not work well Product Backlogs because all Product Backlog Items must ultimately be prioritized in a one-dimensional list. By nesting folders or hierarchies, the priority of individual items nested below the first level is obscured.
There is no right or wrong way to use themes. You can use themes to identify feature sets, the source of backlog items, or just about any other reason you can think of. Themes can be a single word, many words, numbers, or characters.
In addition, Agilefant visualizes themes attached to projects or iterations and their planned "investment level" in the Product Roadmap.
How should you use 'estimated effort left' for a backlog item when there's multiple responsibles?
You should enter the total effort required from all the responsible people; for example, if two people working on a task by pair programming, and they think it'll take three more hours to get done, the estimated effort left should be 2x3h=6h. Likewise, if there's going to be an entire morning (9:00-12:00) sprint planning session with the entire team involved (8 people), the estimated effort left would be 8x3h=24h.
What is the 'default overhead' for a project and how should it be used?
Overhead denotes those things in a project that are during a work week bound to take up time from everyone assigned to the project, but for some reason or another do not make sense to enter as backlog items of their own.
For example, if the project employs daily scrum meetings that on the average take 20min, the default overhead overhead would be 5x20min = 100min.
As another example, you might want to create a project with no backlog items to account for the R&D organization's Helpdesk and user support duties. Based on a historical average, these could take the person assigned to the duty some 3h per week, and if a larger request for support comes up, you can always make a new backlog item to account for it.
Currently, we recommend that you use the project's description to keep record of what things sum up to the project's default overhead. It's easy to forget.
Note that you can adjust the total overheads of individual users from the Dev Portfolio tab. To continue the above example, if one of the people assigned to a project are present only two days a week and thus attends only two daily scrums a week, you would want to adjust his overhead by -3x20min = 1h.
Recording spent effort on development vs. 'sidetracks'
Question: my Manager would like to be able to see how much time we actually get to spend on development (as we are often sidetracked onto support issues.)
I suggest you create a separate project (or several separate projects) for different kinds of 'sidetracks', and create respective project types to denote them; e.g. 'support', and then log effort that goes into that for that project.
Or, you can create a separate backlog item in each iteration for support, make an estimate for it to denote how much time you should spend on it, and log the actual spending.
Why can't you make effort estimates for TODOs?
Agilefant used to have this feature, but we noticed it encouraged making too big backlog items (remember e.g. the rule of thumb from Scrum; if it's over 12h, you don't really know how big it is) so we removed it. And sorry, it's not coming back in the foreseeable future - we suggest you make several smaller backlog items instead 
Why cannot TODOs have responsibles?
We are not too keen on implementing this, and recommend making smaller backlog items instead. See the Feature requests page for further discussion on this and a couple of points that would need answering.
This page
Other pages
Account
Administration
