Evaluation of AgiloPro for Scrum
- 1 Installation
- 2 Configuration & Settings
- 2.1 General
- 2.2 Accounts
- 2.3 Agilo
- 2.4 Ticket System
- 3 Usability
- 4 Adherance to SCRUM Methodology
- 5 References
Environment / Requirements
- Windows users can disregard most of the installation instructions because of the installer.
- Windows users are instructed that they can skip to the configuration section of the installation guide, it would be much better worded to say that they should skip to the configuration since the other installation instructions do not apply to them although is not explicitly stated.
- External libraries section of the installation page does not make it clear that these are not necessary with the windows installer.
- Non-windows users must download python setup tools, and trac. What is not mentioned is that a python installation is required for both of these files to work (if not already installed).
- Worked relatively fast.
- Sensible default values already selected.
- At one point a blank command line prompt appears and remains open and blank for several seconds. This can mislead the enduser into thinking that the installation has failed or crashed.
- Users have to start the server protion of AgiloPro using a seperate file in the folder. This only makes sense for remote usage. The client program should check for this file when started, or at the very latest when the browser returns an error code because the page could not be found.
- Deinstalling also must be completed using the appropriate file in the Agilo folder, instead of using the control panel to do so as with most other windows program.
- Installation only available in english
- Comes over with a high level of familiarity.
- The style is very similar to many other installers.
- Installation is very straight forward and easily understood.
- The size and style of the user interface are very static.
- The 'Choose Components' submenu is not necessary and evidences borrowed code.
- Well structured and easy to read.
- Includes a paraphrasing of more complex clauses for the 'Layman'.
- Font size could be modified.
- Although the font size could be modified to make the words in themselves more readable, the static frame size does not allow for stretching which negates the feature of being able to alter the font size.
- Agreement to the same license agreement was required for the download. In effect users are forced to agree to this twice.
- The style used in the web version of the license agreement was much more aesthetic and should be brought into the client version (if it continues to be found in both places.)
- Minimalistic and easily understood.
- This submenu is largely superfluous since there are only two selectable 'components', and all settings here are also questioned in the following submenus.
- Agilo is a core component and since it is not deselectable its placement here is questionable at best.
- Start Menu Shortcuts is not a component it does not change the way Agilo works, only the way the computer/user access it.
- In the field 'Descriptions' the tooltip says that hovering over a component will display more 'information' about it. However, hovering over the Agilo component only displays the version number. The version number tells endusers no meaningful information since there is no further information specific to the version in the descriptions field or on the website. Hovering over the Start Menu Shortcuts created no tooltip.
- Start Menu Shortcuts must also be activated in the Start Menu Folder submenu to have any affect.
- The file size the component(s) use is listed here, however it is also listed again along with the available disk space under submenu Choose Local Installation.
Start Menu Folder
- Similar to any other installations program and therefor easily understood.
- The checkbox regarding Start Menu Shortcuts either overwrites or completes the same setting in the choose components menu.
Choose Local Installation
- Similar to other installation programs and therefore easily understood.
- Both component size and available disk space are displayed here.
Configuration & Settings
- This trial version displayed errors when performing actions which required data modification. At some point the errors stopped occurring and everything worked as described in the documentation.
- The default field list does not show which users are members of which team.
- In this installation the first several attempts to add a new user creates an error, "AttributeError: 'TracError' object has no attribute 'acctmgr'", even when logged in with admin rights.
- What is Roif?
- Why is the table not sortable?
- The start date has no default value/does not default to the current day.
- Times play no role in the SCRUM development model and are not asked for when creating a sprint. They are however created by default (00:00 on start date and 19:00 on end date) and posted in the list of sprints.
- New team members must be added by name. In concrete terms, without navigation through at least one other trac page new members can effectively not be added unless the administrator has a photographic memory, or are new users which the admin adds implicitly.
- Team mambers cannot be assigned roles in the team from this menu.
- Team members added to this team are automatically removed from other teams without confirmation prompt. Which also means that team members can only belong to one team.
- Deletion of a milestone of which the owner has been removed from the group creates an error. "RuleValidationException: The owner '<username>' of ticket #<#> doesn't belong to the team '<team name>' assigned to this sprint."
- The left menu displays a list of quick links to functions which the user could possibly often use.
- The left menu can be hidden to create a view which more closely resembles that of a standard Trac application.
- Registered users cannot access the Agilo ticket creation menu, although they have these rights by default.
- Accessing new ticket creation through URL manipulation results in the default Trac implementation and not the mask created by Agilo.
- The left (quick) menu is not dynamically generated according to what the user actually does often use.
- Submenus which are accessed using buttons. From a usability standpoint, this program really missed the mark. Dropdown menus under each respective heading would have greatly increased the productivity in that one would no longer have to endure two redirects to get to real functionality.
- Slightly revamped look and feel using colorful buttons instead of flat text to link additional features.
- The menu buttons do not contain submenus linking productive items.
- Mostly standard Wiki features. Experienced Wiki users will feel at home.
- The start page is not selectable from the administrative configuration page. This has the consequence that the inital start page must be copied by hand to to a newly created page in order to create a backup of the intital content with start up instructions, and the default start page must be overwritten to be personalized.
- The creation of new Wiki Articles can only be accessed by URL manipulation. This means to create a new article one has to be at ..../wiki and then add /new_article_name to the end of the URL. This article will naturally not yet be existant, and Wiki will ask if would like to create it.
- The search page allows the (de)selection of multiple types of searchable entries so that one gets results only of the type(s) sought.
- In the top menu there is both a search button and a search field. The restrictions available on the search page would very easily fit under the search field so as to make the button as well as the search page obsolete.
Administrative settings are evaluated under Configuration.
Actions (New Ticket)
- New tickets can be created from the left menu without navigating through submenu pages which are reached via the top menu
- Regardless of which type is chosen, the type can later be changed in the form itself.(Except in Internet Explorer)
- The word 'action' is a misnomer. Every action is an action, not just the creation of tickets.
- A better solution to new ticket creation without navigation would have been a top menu button which opens the ticket creation page with a default ticket type set by the user's SCRUM role. For example Developers can only create tasks (and bugs), pressing the new button should present them with the task creation form, with the option of changing the type to a bug.
- New user stories and tasks cannot reference their parent requirement through the creation interface. This can only be accomplished over other interfaces under certain conditions.
- Drag & Drop
- It should be possible to sort the product backlog by business value, importance or story points. The standard sorting should be requirements by business value and the user story by importance and story points.
Adherance to SCRUM Methodology
The relationship between SCRUM terminology and trac implementation is often very ambiguous.
- Milestone: A milestone is the equivalent to a project or a project part in abstract terms. It is a measure of achievement or level of implementation. It can but must not necessarily have a due date. In concrete terms it is a collection of all the tickets to be worked off for a specific project.
- Component: A software component. A milestone have any number of software components associated with it, or a number of milestones can be set on the path to the creation of one component.
- Ticket: A ticket is an annotation of a development step or suggestion.
- Product Backlog: A list of Requirements organized by business value. The product backlog in a trac environment is equivalent to the milestone. Unfortunately in AgiloPro this is not so implemented. The product backlog in AgiloPro is it's own unit at the upper level, which means in concrete terms one can create floating requirements without relation to any specific product/project. This could have very detrimental consequences at any firm who's trac should handle the projects of multiple teams.
- Requirements: Descriptions of what a product must do.
- User Stories: A description of a specific usage scenario, typically defined by a sentence using the structure "As <role>, I want to be able to <activity> in order to <goal>." Should include acceptance conditions. In AgiloPro userstories cannot be associated with the parent requirement at the time of ticket creation. In the version of AgiloPro used by eStudy trac User Stories could be associated by admins/scrum masters from the product backlog interface or from the ¿user story interface?, however on local installations of the trial verion this feature was not available. It is unclear whether this feature is normally available, and is not found at the most relevant place even if it is. User stories can be associated with a sprint at the time of creation although sprints may not/should not be though out at the time of user story creation. User story importance is not set per default to be compliant to the MuSCoW Method. This can be changed via the administrative settings.
- Tasks: Specific programming activities necessary to implement a user story. The association of tasks to user stories is analogous to the association of user stories to requirements.
SCRUM Planning Cycles & Artifacts
- Sprint Cycle & Backlog: A collection of user stories broken down into tasks which should be worked off during the current sprint. The sprint cycle is realized using trac milestones, this makes it theoretically impossible for more than one project to be dealt with within the same version of AgiloPro for the reasons stated in the criticism to the product backlog.
- Daily Sprint & Backlog (Sprint): A short development cycle, typically one work day, in which tasks are worked off. This is realized using 'Sprint's. The association of user stories to sprints was criticized in the user story section.