To complete the request for a freebie version of agemba, you have to fill out details needed for creating a user profile and a freebie account (aka site) and project.

When you click “Setup Account” you will be redirected to a screen requesting you to login to your newly created project.

Note:

1. You will not be able to change your username (using your email address as the username is not required, but just suggested)
2. The name of the site/account and project will be used both for setting the title and system name. The title of the site or project can be changed later on (by you or another system administrator), but the system name (which is used in the URL and for referencing) cannot be changed without contacting support.

Inviting Users

In order to add a user, you need to invite him first. The invited person then receives an email with a link, which he must activate to confirm the invitation and create his user account.

The invite information only includes the users email address, so no personal information as for instance name and phone number is added in Agemba before the user himself chooses to enter this information.

User Roles and Teams

A user can have different roles and thereby have acces to view, edit or perform different tasks. When you invite a user, you specify, which role (Limited User, Ordinary User or Manager) the user will have. You can also assign him to one or more teams in the circle, whereby he will indirectly get a role. Read more about circle roles or site roles.

You can change the role and teams for existing users.

How to see and add Users?

Select “Manage Users” from “More” in the Main Menu.

Assigning Stories and Mentioning Users

Users in a Circle can be assigned Stories and also mentioned in comments and descriptions in general.
The users will then be notified via email if they have not logged into Agemba to see the assignment or 
mention.
While this is possible, it is recommended to add users to teams and then assign or mention
the team.

Epic are larger stories. In the Storymap Tree you can have as many levels of epics as you like to describe the project. Once you reach a level which cannot be broken down into smaller parts, you create stories. 

Epics can be planned to releases, but cannot be put in sprint – only stories can go into sprints. 

The state of the epic will always follow the state of the stories/epics below it.

A circle is a unit or project within the organization containing one roadmap and one product backlog. From the Scrum perspective, you can look at it as a team responsible for a specific part of the work in the organization.

You assign (invite) users to the circle.

In the Storymap view, all the items in the Storymap Tree are shown top-down. You may choose to show only part of the tree by selecting Why, What, Who or When from the menu at the top. If you want to show contents from only a specific card and down, then click on the card to make it current. The card will then appear in the selection menu at the top.

Panes

Three panes are available in the Storymap view. You may select different parts of the tree in the different panes and including last selected from the pane’s dropdown; see example in screendump below:

You can drag items from one pane to another. This makes it easier to move items or create relations between subtrees.

Relations

A relation could be that a story is part of a sprint. The relation is shown as a line between the story and the sprint cards. You can hide or show different types of relations in the View menu at the top. 

Click here to see different types of relations.

Move this entity to a different place in the StoryMap tree. This may require a type conversion.

Acceptance Criteria

In this tab you can add and see a list of acceptance criteria for the current entity (story, epic etc.).

You can change the state of each acceptance criteria by clicking on the “Edit” button and select a new state. There is currently no workflow concerning the state of the Acceptance Criteria. It is only used as information to the user.

Product Backlog View

In the Product Backlog View you can prioritize epics, stories etc. and order these in releases and sprints. Unplanned items can be dragged in from the left pane.

Release and Sprint Main Pane

In the right pane you can view and add releases as shown below:

You can then create sprints within the releases.

You can drag items (epics, stories, issues etc) into a release or sprint. Use drag and drop to reorder items. If you want to remove an item from the release or sprint, right-click on the item and select “Remove from Release”.

Kanban Lanes

Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

A Kanban lane can be created here and will appear right below the last Release lane. See Kanban lane for more details.

Indirectly Planned Cards

If you drag an epic to a release and the epic has unplanned child stories, these are indirectly planned to the release. But only the epic card (not its child cards) are visible in the release. This is to simplify the view.

The indirectly planned children are only shown in the left pane in the “Detailed Planning” mode described above. They are not shown in the left panes other lists with unplanned items.

If all the children of an epic or theme are planned to releases or sprints, then the parent item is indirectly planned to the last release containing one of its children.

You can see on the card icons, if it is planned to a release or sprint. If you open the modal window for a story or epic, you can see, to which release or sprint it is planned directly or indirectly.

Preplanned List

A Preplanned list can be included in the Product Backlog in very much the same way as a Release. 

A site is an organization account.

Within a site you can create one or more circles. It is the circles that contain Product Backlogs, teams, milestones etc.

Most users belong to one site and have access to one or more circles within the site. It is possible though, to have access to more than one site.

At site level you create the circles and define the relationships between circles (in the Circle Map).

In the Dashboard view at site level, you can see items and activity log across circles within the site. 

Release Card

A release is a special type of milestone. It is the base for the planning in the Product Backlog. 

Releases are displayed as cards in the Storymap Tree in the “When” section. Releases may contain one or more sprints.

Effort Estimate

You can estimate the effort which it will take to implement the story.

An effort estimate is given as both a 50% value (I am 50% sure that the story can be completed with this estimate) and a 90% value (I am 90% sure that the story can be completed with this estimate). Logically, the 90% value is always the largest.

The size of stories is estimated in story points  (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100).

Smaller stories can usually be estimated more precisely. Therefore the distance between available story points is smaller at the start of the range.

If the story is too big to be included in a sprint or too complex to be developed, then you should create it as an epic instead.  Before implementation, the epic should be split into more smaller stories (created as children of the epic).

Value Estimate and Kano Type

Likewise, the value of the story can be estimated. First you have to access whether this story even has a value or if it is too small to have a value of its own. Then you evaluate its value type based on the Kano assessment.

If the story is a Must have, then there is no point in determining the value – it needs to be implemented no matter what (and the value is therefore automatically set to follow the effort estimate).

If the story on the other hand is an Exciter or a Satisfier, you can set the value estimate as a 50% and 90% number (I am 50% that the value is this high, but 90% sure that the value is at least this high) – the 90% number is logically the lowest.

If the story is of Kano type Indifferent or Reverse, then it obviously has no value.

Effort and Value Aggregation

Both the effort story points and the value estimations are summarized to the above level in the Storymap Tree. If no value has been entered, a default value (e.g. 5) is used in the calculation.

Ideas can be both concrete suggestions as well as more vague comments about how end-users see the product/outcome of the project. They could for instance be the result of a user survey.

Ideas are placed in the “Why” part of the Storymap Tree. 

Storymap Tree

All stories, issues, milestones etc. in Agemba are organized in the  Storymap Tree. You can view and maintain the tree structure in the Storymap view (tree is shown as cards top-down) or in the Outline view (tree is shown as an indented list tree).

The Storymap Tree has four main branches from the top of the circle:

The “Why” section

Includes ideas and issues, impediments and improvements. 

Ideas and issues are often based on direct input from users. More users may have reported issues, that are partly overlapping. Or they may come up with similar ideas explained from different user perspectives. 

The entities can be organised below a tree of the corresponding epics. One grouping could include issues from a specific customer or ideas from a user event. Or ideas could be grouped depending on the type of idea addressed.

Issues and ideas in the “Why” section will often be implemented by stories in the “What” section, see description of an Implemented Relation. They can also be planned directly to a release or sprint.

The “What” section

Includes stories and infrastructure stories. 

Entities in the “What” section are also organised in a tree structure, where epics may contain other epics. Stories are the leaves of the tree. At the top of the “What” subtree, epics can be grouped into themes.

Epics are not just for grouping. Like stories and ideas etc., epics also has a user story text.  If a user story is too big (in effort time) for a sprint, you should create an epic. Below the epic you can detail the user story of the epic into smaller stories. Implementing all the stories below an epic means that the epic is implemented.

The stories in the “What” section are typically more concrete and “worked through” than the ideas in the “Why” section. In an organised way, they describe “what” is going to be features in the product. As mentioned above, stories and epics may implement issues and ideas from the “Why” section.

Infrastructure stories are basic features described in a more technical way. Ordinary stories and epics will often depend on these to be finished first, see the description of Dependency Relations. 

The “Who” section

Includes User Personas.

You can create a User Persona to represent a customer, an internal group or any other person or group. You can then create e.g. Interest Relations from this User Persona to epics or stories.

This makes it easy to keep track of the stories, which e.g. a customer has an interest in.

The “When” section

Includes Milestones, Releases and Sprints.

The “Inbox” and “Heap”

See Inbox and Heap overview. 

Outline View

In the Outline view you see the Storymap Tree as an indented tree list for each of the sections “When”, “What”, “Why” and “Who”.

How to create Stories, Epics etc.?

You can add children (stories, epics etc.) to the trees by right-clicking on an entity and select the type, you want to create, from the menu. 

Show more details in ‘When’ section

There are certain views that have been included in the ‘When’ section that can be enabled and disabled at the user’s will. By default, the ‘Outline View’ is the selected view and it shows a tree list of the releases, sprints and milestones just like other entities in the other sections. The alternative view is the ‘Timeline View’ and this simply shows the releases, sprints and milestones within a timeline. These can be switched from the hamburger menu as shown in the screendump below:

While in the ‘Timeline View’, additional views are made available for the user to switch between. These are:

• Timeline Compact View – will only show releases, sprints and milestones on the timeline. It’s also the default view.
• Timeline Full View – will include the epics/stories along with what is shown in the compact view above.
• Labels – adds labels (titles) to the entities that are shown on the timeline.

See screendump below:

Circle Map

The circle map is for organizations who wish to have more than one scrum team, where each team has their separate Product Backlog.

You can have one or more Primary Circles, each with their own Product Backlog. Other types of circles (Customer Circles, Supplier Circles etc.) also have their separate Product Backlog.

Delegation of User Stories between Circles

If you add a relation from e.g. a Customer Circle to a Primary Circle (called “Development” in the illustration), it means that the team in the Customer Circle can delegate user stories from their Product Backlog to the Primary Circle for implementation.

Please see Delegate to another circle for more details about delegation.

Circle Manifest and Traffic Light

Each circle should have a Manifest describing the purpose and scope or the circle. If you place the cursor over a circle, a popover will show the manifest.

If there are some problems in the circle, you want to draw attention to, you can change the traffic light of the circle to yellow or red. Write a traffic light comment to describe the problems. The traffic lights are shown at the right side of the circle cards.

Teams in Circles (Read More)

A circle has one Product Backlog and usually one team to handle the backlog contents. However, you also have the option of dividing users in to multiple teams within the circle.

How to create a Circle and Relation in the Circle Map?

To add a new circle, right click on the circle map and select the circle type in the context menu. The new circle added will also be available in the circle selection in the Main Menu (Read More).

To create a relation between two circles, hold down the “Alt” key while you drag the relation from one circle to another.

Planning Relations

In Agemba you can create the following planning relations to milestones, releases, sprints and preplanned lists.

• • Milestone Relation
    If you add a relation from e.g. an epic to a milestone, it means that the epic must meet the deadline of the milestone. 
    You can have relations to milestones from: stories, issues, ideas, impediments, improvements, notes, epics and themes.
  • Release Planning Relation
    A relation from e.g. an epic to a release means that the user story described in this epic will be part of the release.
    You can have relations to releases from: stories, issues, ideas, impediments, improvements, notes, epics and themes.
  • Sprint Planning Relation
    A  relation from e.g. a story to a sprint means that the user story described in the story will be part of this sprint backlog. A sprint is always part of a release, so the story will also be part of this release.
    You can have relations to sprints from: stories, issues, ideas, impediments and improvements.
  • Preplanning Relation
    A  relation from e.g. an epic to a preplanned list means that this epic is not yet planned to a release but merely “preplanned”. Preplanned lists are for grouping the epics in what might become a release with a specific release date. It is for ordering epics and emptying the list of unplanned stories shown in the left pane of the Product Backlog.

Note that you cannot have a relation from a theme, epic or note to a sprint. The typical way to work is that you drag an epic to a release in the Product Backlog window. Before and during the sprint planning, you detail the epic into stories. You then add the stories to the sprints.

Implements Relation

If an idea is implemented by a story, it means that the story “includes” the idea during the implementation and during the planning. The idea is not planned to a release or sprint by itself but via the story.

You can still see the state (Created, Done etc) on the idea card, but it will to some extend mirror the state of the implementing story. So if you set the state of the implementing story to “Done”, it should mean that the story and the ideas, it is implementing, are all done.

It is always an entity in the “What” part of the Storymap Tree (story, infrastructure story or epic) that implements an entity from the “Why” part of the Storymap Tree (issue, idea, impediment, improvement or the corresponding epics).

Dependency Relation

The “Dependency” relation means that a:

• Story or epic

waits for an:

• Infrastructure story or infrastructure epic

to be completed, before it can be completed.

Interest to Relation

An interest relation can be setup to describe that a given functionality is of interest to a user persona. This is primarily for categorizing stories according to user personas and will not have any impact on the workflow.

How to see a relation in Agemba

All non-planning relations are shown in relations tab.

In the Storymap view you can see the relation as a line between two cards (e.g. between a story and a sprint card). In the Product Backlog sprint you will just see the story in the release or sprint box.

Sprint Backlog View

The Sprint Backlog view is a daily tool for the sprint team to keep track of the sprint progress.

Stories with the highest priority have been added to the sprint in the Product Backlog view. The total effort estimate of the stories in the sprint must match the resources available in the sprint period. 

Each Team in a circle has its own tactical queues, zero to one set of Sprints (a series of non-overlapping lanes) and 0-N Kanban lanes. If there is more than one Kanban lane, it will be because the Team offers different classes of services, e.g. different workflows for different service requests.

Tasks can be created directly in the lane a Story is in, using the icon.

“State” Lanes

In the Sprint Backlog view, the team creates tasks for each user story. The Sprint Backlog view has lanes for “To Do”, “Progress” and “Done”. All stories with their tasks start in the “To Do” lane. When a task implementation is initiated or finalized, it is moved to the next state lane. Lanes running across columns with sub-states will be denoted with “DONE” to indicate completion in that sub-state.

Kanban Lanes

Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

If created in the Product Backlog, Kanban lanes will appear right below the Sprint lane as can also be seen in the screen dump above. See Kanban lane for more details.

Note Card

In the initial high-level planning in the Roadmap, you may not want to care about types (epics, stories etc). Instead you may create all the draft activities as notes. Notes can afterwards be converted to specific types in the detailed planning .

Notes are visible in the Storymap Tree like all other items. If they are created via the Roadmap, they are placed below themes in the “What” part. You may also create notes below epics directly in the Storymap or Outline window.

Why notes should be converted to other types?

Notes are meant to be used in the first draft planning. They are easy to delete, if you change your mind about the planning activities. Notes cannot have children in the Storymap Tree (like themes and epics), and they do not have a state. This means that you cannot set the note to e.g. “Ready” or “Done”.

In the detailed specification in Storymap or Outline windows, you will usually convert notes to epics or stories.

Edit Details

In the “Edit Details” tab you can edit basic information like title, user story, value estimates, effort estimates etc.

When you finish editing the information, you need to press one of the “Save” buttons at the top of the tab. If you don’t want to save your changes, you need to press “Discard” before you can close the modal window.

Comments

In the “Comments” tab you can view and write comments concerning the item. You can also make replies to existing comments.

Make Comments to Specific Users or Teams

If you want to be sure, that specific users or the users of a team are reading your comment, you can mention the user or team in you comment. Write “@” in your comment followed by the user or team name. 

As soon as you write @, a popup list with users and teams will appear. Select the user or team, you want to address. 

Read more about editing comments here.

How does the User see his Unread Comments?

The user will now see a wide button in the activity logs, to inform him, that he must read and confirm the comment.

In addition to this, a digest mail to the user will include his unread comments. The frequency of digest mails depends on the system setup. I.e. whether it is send once a day, once an hour or with some other time interval. The digest mail is only send, if there are new comments or assignments made after the previous digest mail.

Activity Logs

In this tab you can see a history log of all the changes made to this entity. This includes:

• Changes made by the user in the “Edit Details” tab in the modal window.
• Changes made by the system as a result of other changes. For instance the aggregated Value Estimation on an epic is updated by the system, if a user has changed the Value Estimation for a child story.
• All comments added by users for this entity. 

Filter Logs

At the upper right corner of the Activity window, you can select different filters to limit the logs displayed. For instance you can choose to show “Activity without system logs” to show only changes made by users.

You can also choose to see comments only. This is the same as displayed in the “Comment” tab. But in the “Activity” tab, you have filtering options (unread comments etc.), which you do not have in the “Comments” tab. This is to keep the “Comments” tab simple, while providing the more complex flexibility in the “Activity” tab. 

Overview Tab

In this tab you get a read-only overview of the basic information as well as a list of relations, attachments etc for the current element.

The exact information displayed depends on the type of entity (story, epic, release etc.)

Note that the same information can be seen in the Right-Panel Details overview.

Attachments Tab

The “Attachments” tab shows all the images and files uploaded to the current entity.

Upload and add Links from Text Editor

When you are editing a text (a user story, a description, a comment etc.) you can insert an image or a link to a file in the text. If you drag a file to the editor area, the file is automatically uploaded as an attachment and a link to the attachment is added in the text. 

Note: The editor area needs to be selected in order to paste any content from the clipboard.

You can also link to an already uploaded file or image from the text editor. If you click on the image icon in the editor menu, a window with the images and files uploaded for this entity is opened. Select the file to link to.

Upload directly in the Attachment Tab

You can also upload files directly in the attachment tab. These are not linked to from any texts, but you can add the links from the text editor afterwards.

Milestone Card

Basically, the milestone specifies a deadline. Milestones are visible as cards in the Storymap Tree in the “When” section. 

Themes, epics and stories etc. can be linked to the milestone to indicate that they must meet the deadline.

In Outline, milestones can be shown in the timeline. In Roadmap they are placed in a special lane.

Milestone Types

There are different types of milestones (delivery in, delivery out etc.). They work basically the same but the type indicates the kind of deadline to the reader of the Roadmap, Outline etc.

A release is a special kind of milestone. Like a simple milestone, it has a deadline. But it is also the base for the Product Backlog planning.

Relations from Themes, Stories and Epics to Milestones 

You can link stories etc. to the milestone in different ways:

1. From Roadmap and Storymap: Hold down the “Alt” key and drag an arrow from the theme, epic or story to the milestone.
2. Open the theme, epic or story modal window (double-click). From the “Relations” tab, you can select a milestone.
3. Open the milestone modal window. From the “Relations” tab, you can select stories etc.

The above ways are also possible to link stories etc. to a release or sprint. Normally you will however use Product Backlog for the planning of releases and sprints.

Go to Storymap and show this entity in the Storymap tree.

Change state of entity. Set this state, if the story is not relevant (at least for now).

Changes the state. Means that the entity has been described and is ready for implementation.

Go to Outline and show this entity in tree.

Changes the state. Means that you want to start preparing the story.

List View

You can access the List view from the Main Menu in both “site” and “circle” mode. If you are in “site” mode, the lists will show items for all the circles within the site. If you are in “circle” mode, only items for the current circle are displayed.

From the List view you have access to various lists of epics, stories, releases etc. For each list is defined, which columns to show and a filter is defined to select the items to include in the list.

Select which list to display

A number of predefined lists exists.

At the top menubar you can see the name of the current list (“Issues only”).

You can switch to see a different list via the menu.

Some users are allowed to create their own lists. Therefore the available lists shown in this example may not be the same as the ones, you see.

Pages and page size

If the list has many items, the items are shown at more pages. You may change, how many items are displayed at one page by selecting “Page Size” from the “View” menu.

At the bottom of the browser window, you can navigate to the previous and next pages. If you scroll through the items with the “Arrow up/down” key on the keyboard, you will automatically move to the previous/next page when you reach the top/bottom.

Search for Contents

If the list is long, you may also want to search for specific items within the list.

In the search field at the upper right, you can enter a search text. This is a so-called freetext search, meaning that you will get all items of the original list, where the search text is part of the title, the user story, attachments etc. You can also enter a specific id in the search field.

If you want to make a more column specific filtering (e.g. only show specific types or items after a create date), you can open a row with filter input fields. Open the filter row be selecting “Show Filters” from the “View” menu.

In the example, the user has entered a filter showing “Story” type only. He could have chosen more than one specific types and only some states.

Detailed information about item

If you press the button at the right corner of the list view, a sidepanel is opened. It shows the details of the currently selected item.

Export to Excel or PDF

From the “Tools” menu you may export the currently selected list to Excel or PDF.

Advanced View

Depending on your user profile, you may have access to Advanced Mode. Select “Advanced Mode” from the “View” menu to activate this. More menu entries will then appear in the “View” menu and more selection boxes will appear in the top menu for the List view.

Teams

A circle can have one or more teams of users. A user can be part of more teams.

Teams and Circles

In general you should consider the users of a circle as one team. They have one Manifest and one Product Backlog. It is good practice to create a basic team in the circle with all users in the circle.

But you can also create more teams with certain responsibilities. E.g. a team with all developers in the circle. This makes it easier to assign comments or tasks to a group of people.

Team Roles

You must assign a role to a team (Limited User, Ordinary User or Manager). All users in the team get this role. Some functionality in Agemba is only available for users with a certain role (e.g. to create teams).

How to add Teams?

In the “More” Main Menu select “Circle overview”. In the “Teams” tab, you can add teams.

Note that not all users in the circle are allowed to add teams (depends on permissions/role). But all the users can see the list of current users and teams in the Circle overview.

Open Right-Panel Details Window

From some of the main windows (StoryMap, List etc.), you can open and close a “details” window by clicking on the  icon at the right side border of the main window.

If you open this window, it will show details of the story, epic etc. currently selected. Click on a card in the Storymap or a list item in the List view to see the details.

The Agemba Main Menu

The main menu gives you access to the different windows related to the current Site and Circle. You can see the name of the current Site and Circle on the menu bar. If you have more Sites or Circles, you can switch to these (Read More).

“Site” Menu Entries

• Dashboard
• Circle Map
• List

“Circle” Menu Entries

• Dashboard
• Roadmap
• Outline
• Storymap
• List
• Product Backlog
• Sprint Backlog

Current Site and Circle

In the main menu, you can see the Site and Circle, on which you are currently working (marked with red in the figure below).

In the figure example, the user is currently working on the site called “AgileLeanHouse” and on the circle (i.e. project) called “Website”.

Switch to a different Site or Circle

If you have access to more circles within the site, you can switch to a different circle in the menu (arrow-down icon next to the current circle name). For users with access to more sites, they will also see a menu arrow next to the site name, where they can switch to a different site.

Toggle menu entries for Site or Circle

In the main menu, you can switch between seeing menu entries relevant for the current “site” and menu entries relevant for the current “circle”. You can toggle between these two modes by clicking on the site name or on the circle name.

In the above figure, you see the menu entries relevant for a site (because the user has clicked on “AgileLeanHouse”). The views relevant for a site are typically overview information across circles within the site.

Sprint

A sprint is a time-box of one month or less after which a “Done”, useable, and potentially releasable product Increment is created (this is the official definition in the Scrum Guide).

Sprints are visible as cards in the Storymap Tree below releases in the “When” part.

Sprint Planning

In most cases, sprints are created in the Product Backlog. A release may contain one or more sprints with a start and end date. In the sprint planning, the Product Owner and the team will add stories spanning the time period in effort days.

The team can define tasks for each story to further detail implementation chunks. Tasks are created in the Task tab of the story modal window or in the Sprint Backlog.

Note: You can only add stories, issues and ideas to the sprint. Not epics or themes.

Sprint Implementation

During the sprint period, the team will mark the tasks as done, while they finish each task. Agemba will automatically set a story to done, when all the story’s tasks are done.

The team uses the Sprint Backlog to change the state of stories/tasks and to follow the progress.

Story Cards

Stories are visible in the StoryMap Tree in the “What” section. Like epics, ideas etc, it has a user story text describing a request seen from the user perspective.

Epics vs Stories

In the Storymap Tree, epics and stories are visualised as parents and children in a tree. The epics are the parents with the high-level user stories, and the stories are the children with the smaller (in effort time) user stories.  

If a user story is too large to be completed in one sprint it should be created as an epic.  The epic card can then have a number of story card children. In general the child stories should cover the requirements of the parent epics.

It is not always obvious in the initial planning, whether an epic or a story should be created. You can later on convert a story to an epic and vise versa. There are some limitations, though.  For instance you cannot convert an epic to a story, if it has children. And you cannot convert a story to an epic, if the story is already placed in a sprint (because epics cannot be placed in a sprint).

The Roadmap is a high-level overview of milestones and steps. It gives you a starting point for your initial planning as well as a top-level view of the progress. The planning may be detailed in Outline, StoryMap and Product Backlog.

Add Lanes (Themes/Infrastructure-Themes) to the Roadmap

Initially the Roadmap contains a “When“ lane where you can add milestones (see below).  

In addition to the “When” lane, you may add lanes in the Roadmap for each theme and infrastructure-theme, you want to be visible in the Roadmap.  When you add a lane, you can either:

1. Create a theme/infrastructure-theme for the new lane directly in the Roadmap. The new theme will also be visible below the “What” section in the StoryMap tree.
2. Select an existing theme from the StoryMap tree and use this theme as the base for the new lane.

You can create or add a theme lane from the “Add” menu. A menu list with the options described above will be shown.

How to get started with Milestones?

As mentioned above, the Roadmap contains a “When“ lane where you can add your milestones. Right-click on the lane and select the type, you want to create. You may also create a release as a special type of milestone. The stories in the release can later on be detailed in the Product Backlog.

Milestone Deadline

The default deadline of a new milestone depends on, below which date you right-click in the lane. 

You may afterwards change the deadline by double-clicking on the milestone card and edit the date in the input window or by dragging the milestone item to the left or right. Dragging can be enabled and disabled from the Tools menu located at the top-left or from the item’s context menu.

Plan Stories and Epics in the Theme/Infrastructure-Theme Lanes

You may now start the planning of contents in the theme lanes. You can add stories and epics already created in the Outline or StoryMap tree windows.

In the initial draft planning you may instead choose to create notes directly in the Roadmap. The notes created in the Roadmap will also be visible in the StoryMap tree below the themes. The notes can later on be converted to stories or epics.

Connect Items to Milestones

You may specify that a note, epic or story is related to a specific milestone or release. Hold down the “Alt” key and drag from the note/epic/story to a milestone or release card. A line is drawn to indicate the relation. The new relation also exists, if you view the items in the StoryMap or Outline.

Site and Circle Dashboards

Agemba has two dashboard windows, one at site level and one at circle level. You can access the Dashboard window from the Main Menu.

What is a Dashboard

A dashboard page contains a number of dashlets with relevant focus lists, activity logs, charts etc. If more than one page is needed, you can switch between pages by clicking on the arrows at the page sides or the bullets at the top.

More Dashboards available

You may have more dashboards available at site or circle level. From the menu at the top right of the window, select “Show Dashboard List”. A panel with a list of dashboards and dashboard pages then appears. Click on a dashboard or page to switch to.

What are User Stories (descriptions)?

User stories are descriptions of a feature told from the perspective of the person who desires the new functionality. They typically follow a simple template:

     As a < type of user >, I want < some goal > so that < some reason > before <some time >.

You will probably have some requirements from customers, others from different types of ordinary users etc.

The when part of the user story can be set using the Required When date.

Relations

In the “Relations” tab you can see and/or add relations between entities. You can see a description of the different types of relations here. Note that planning an item is done in Edit Details form, read more here.

The view shows all the types relations that can be added for this specific item. When a relation is created it can carry a description, which explains the purpose of this relation. An existing relation can be edited (to update the description) or deleted.

If you want to create a new relation from the current item, start typing the id or title of the item, to which you want to create a relation, or browse to find the item by clicking the folder icon.

If you want to check out agemba before deciding on whether to buy a license, you can get a freebie version.

In this version you will be able to check out the functionality in agemba in a single circle (aka project) and add a limited number of other users.

Note that some features such as tactical planning in sprints, issue tracking, working with teams, etc are not available in the freebie version.

When you request a free agemba account, a confirmation email will be send to the email address you submit. You can then follow the link in the email to setup you account.

Agemba-Jira integration

What does integrating Agemba with Jira mean?

The whole idea behind integrating Agemba with Jira is simply to allow strategically organized work (Stories) in Agemba to be delegated to Jira for implementation. With this structure, a clear-cut overview is still maintained in Agemba while implementation in Jira is uninterrupted. As such, there will not be any pressure for development teams that are highly effective in working with Jira to have to readjust to the introduction of Agemba. It is important to note that this is different from what would qualify as a Jira Plugin which would require installing it onto Jira.

Preconfiguration

Before Jira-syncing can be enabled in Agemba, some configuration is required both in Jira & Agemba. The assumption here is that a Jira project is already setup or should be setup before proceeding with the rest of the steps outlined from this point on.

Prepare Jira User
A Jira user is required to facilitate the process of syncing a Circle (project) in Agemba to a Jira Project. Such a user should have the Jira permissions Create Issues, Edit Issues and Add Comments. By default, these permissions are auto-set in the Jira user groups jira-core-users & jira-software-users. Therefore a user belonging to these groups should suffice.
NB: This user should NOT have Admin rights.

Create API Token for Jira User
An API token is necessary for authorizing Agemba as an API in Jira with the Jira user created in the section above. This needs to be created manually following the process described below:

• Login to https://id.atlassian.com/manage/api-tokens using Jira user credentials.
• Click API tokens, then Create API token.
• Use Copy to clipboard, and paste the token to your somewhere secure and easily accessible.
• Alternatively, follow the guide here for an updated version on how to create an API token.

Setup Jira Sync License Module in Agemba
A special license module is required to be able to sync a Circle with a Jira Project, at the Site level in Agemba. A Site Admin can do this from the License Tab in the Site Overview Modal view in Agemba just like with any other license module. Once this license module has been setup, then any of the Circles within that Site can be synced with a Jira Project.

Configure Jira Sync Properties for Agemba Circle(Project)

NB: To proceed with this, the preceding steps above must have been followed.

For every Circle that is to be synced with a Jira Project, certain Jira properties must be configured in that Circle in Agemba. Below is a Screen dump of Jira Configuration for a Circle:

Configurable Jira properties in Agemba are:

• Jira Sync Status
  A display only field, that indicates the current status of the Circle synchronization with the configured Jira project. It can be;
  • Paused – Syncing has been deliberately set on pause.
  • Active – Syncing is currently enabled for this Circle.
  • Invalid Credentials – Syncing failed because the Jira credentials provided could not be authorized in the supplied Jira Server Url.
  • Invalid Project Key – Syncing failed because the supplied Jira Project Key could not be found in the supplied Jira Server Url.
  • Jira User Permission Check Failed – Syncing failed because the provided Jira Server User Name does not meet the permission requirements. Please see the Jira Server User Name point below.
  • Connection Error – Syncing failed because connection to the Jira Server Url supplied could not be established; possible reason could be that Jira is down.
  • Unknown Api – Syncing failed because the data received from the supplied Jira Server Url could not be processed by Agemba. This would most likely mean that Api version of Jira is different from what is supported in Agemba.
  • Corrupted – Syncing failed because of an internal failure in Agemba during the process of syncing data. This situation requires action to resolve. 
  • Unknown – Syncing failed and the reason could not established decisively.This situation requires action to resolve.

• Jira Project Key
  The unique identifier value of the Jira project to sync the Agemba Circle with. It usually starts with an uppercase letter followed by one or more uppercase alphanumeric characters and max length is 10 characters.
• Jira Server Url
  The Http path that points to the Jira instance that this Circle will be synced with;
  e.g ‘ https://your-domain.atlassian.net’
• Jira Server User Name
  The dedicated username for the user, in Jira, that will be used by Agemba to synchronize with the project in Jira. See the Prepare Jira User section above.
• Jira Server Api Token
  See Create API Token for Jira User section above.
• Jira Status Map
  Map the possible Jira Issue statuses with the corresponding Agemba states. This is necessary so as to be able to sync the state of a delegated Agemba Story to the status of the corresponding Jira Issue. As such, it is only allowed to have a single Jira status mapped to an Agemba state. Jira Statuses are loaded automatically from Jira.
• Jira Type Config
  This section(s) of the configuration shows the Jira Issue type and what Agemba Story type it is mapped to. If there are any compulsory fields for that Jira Issue type that have to be set when creating in Jira, it will listed to be configured. The configured compulsory fields will then be used as default values when creating the Issue in Jira.
  A Label can optionally be set to be used to label Issues created in Jira, from Agemba. 

Test Jira Connection
There is a possibility of testing Jira properties of a Circle at anytime which also includes before saving them. This can be done using the ‘Refresh Config from Jira’ button found at the top left corner of the Jira Configuration Tab. This will also load any missing configuration fields from Jira.

Updating Circle Jira Properties
Some of the configured Jira properties on a Circle in Agemba can be updated or changed, more specifically; Jira Server User Name, Jira Server Api Token, Jira Status Map and compulsory fields under Jira Type Config. The other properties i.e Jira Project Key and Jira Server Url cannot be changed or updated once set.

Delegating Agemba Story to Jira
Once the Circle in which a Story resides in has been successfully synced with a Jira project, it will be possible to delegate that Story to that Jira project. Delegation to Jira can be done from the Story’s menu in Agemba; see the sample screen dump below:

Delegating an Agemba Story to Jira will result in the creation of a Jira Issue with a similar title and description composing of a merge of the user story and detailed description in Jira. Editing of the Agemba Story will consequently be restricted and its state will be in-sync with that of the corresponding Jira Issue. Information about the Jira Issue will be made visible on the Story in Agemba including the status of the delegation & syncing process. The Delegation Status shows the status of the sync process of the Agemba story with the corresponding Jira Issue. Delegation Status can be:

• Pending – Indicates that the delegation process i.e creation of a corresponding Jira Issue for the Agemba story is not yet complete.
  NB: This status should not be interpreted to mean that the process failed or succeeded.
• Synced – Indicates that syncing with corresponding Jira Issue is active and the state of the Agemba story will be in sync with the status of the corresponding Jira Issue.
• Syncing Failed – Indicates that syncing failed and the Agemba story will not be in sync with the corresponding Jira Issue.
• Unsynced– Indicates that syncing between the Agemba story and the corresponding Jira Issue was deliberately stopped by the system, either because it was determined as completed i.e set to ‘Closed’ during syncing or as a consequence of canceling Circle syncing with Jira project altogether.
• Unknown Jira Status – Indicates that mapping of the Agemba story’s state to the read status of the corresponding Jira Issue failed. The reason could very likely be that the JIra Status Map configuration on the Circle level was not setup correctly.
• Corrupted – Indicates that either the delegation or syncing process of the Agemba story failed because its data was corrupted.
• Uknown – Indicates that the system encountered a situation that was not anticipated during either delegation or syncing of the Agemba story.

Undelegating Agemba Story from Jira
A simple form for undelegating from Jira where a Story is disconnected from the corresponding Jira
Issue that was created, has been implemented. This can be done from the Story menu in Agemba and will result in the Jira Issue summary(title) being prefixed with [UNDELEGATED].

Story State, Title & Jira Descriprion Sync
Once a Story is delegated, its state, Title and Jira Description will be kept in sync with that of 
the corresponding Jira Issue.

If you configure a Jira connection for a circle, it will be possible to delegate stories in the circle to the specified Jira project. You need to enter the following information:

NB: General information about Agemba-Jira integration can accessed here. 

• Jira Sync Status
  A display only field, that indicates the current status of the Circle synchronization with the configured Jira project. It can be;
  • Paused – Syncing has been deliberately set on pause.
  • Active – Syncing is currently enabled for this Circle.
  • Invalid Credentials – Syncing failed because the Jira credentials provided could not be authorized in the supplied Jira Server Url.
  • Invalid Project Key – Syncing failed because the supplied Jira Project Key could not be found in supplied Jira Server Url.
  • Jira User Permission Check Failed – Syncing failed because the user connected to the provided Jira Server User Name does not meet the permission requirements. Please see the Jira Server User Name point below.
  • Connection Error – Syncing failed because connection to the Jira Server Url supplied could not be established; possible reason could be that Jira is down.
  • Unknown Api – Syncing failed because the data received from the supplied Jira Server Url could not be processed by Agemba. This would most likely mean that Api version of Jira is different from what is supported in Agemba.
  • Corrupted – Syncing failed because of an internal failure in Agemba during the process of syncing data. This situation requires action to resolve. 
  • Unknown – Syncing failed and the reason could not established decisively.This situation requires action to resolve.
• Jira Project Key
  The unique identifier value of the Jira project to sync the Agemba Circle with. It usually starts with an uppercase letter followed by one or more uppercase alphanumeric characters and max length is 10 characters.
  NB: Updating this property is NOT allowed.

• Jira Server Url
  The Http path that points to the Jira instance that this Circle will be synced with;
  e.g ‘ https://your-domain.atlassian.net’
  NB: Updating this property is NOT allowed.

• Jira Server User Name
  The dedicated username for the user, in Jira, that will be used by Agemba to synchronize with the project in Jira. The required permissions include Create Issues, Edit Issues and Add Comments. By default, these permissions are auto-set in the user groups jira-core-users & jira-software-users. Therefore a user belonging to these groups should suffice.
  NB: This user should NOT have Admin rights. 

• Jira Server Api Token
  A special access token needed for authorizing Agemba in the Jira server as an API. This needs to be created manually following the process described below (valid as of December 2018):
  • Login to https://id.atlassian.com/manage/api-tokens using Jira user credentials.
  • Click API tokens, then Create API token.
  • Use Copy to clipboard, and paste the token to somewhere secure and easily accessible.
    Alternatively, follow the guide here for an updated version on how to create an API token.
• Jira Status Map
  Map the possible Jira Issue statuses with the corresponding Agemba states. This is necessary so as to be able to sync the state of a delegated Agemba Story to the status of the corresponding Jira Issue.  As such, it is only allowed to have a single Jira status mapped to an Agemba. Jira Statuses are loaded automatically from Jira.
• Jira Type Config
  This section(s) of the configuration shows the Jira Issue type and what Agemba Story type it is mapped to. If there are any compulsory fields for that Jira Issue type that have to be set when creating in Jira, it will listed to be configured. The configured compulsory fields will then be used as default values when creating the Issue in Jira.
  A Label can optionally be set to be used to label Issues created in Jira, from Agemba. 

Test Jira Connection
There is a possibility of testing Jira properties of a Circle at anytime which also includes before saving them. This can be done using the ‘Refresh Config from Jira‘ button found at the top left corner of the Jira Configuration Tab. This will also load any missing configuration fields from Jira.

An epic/story can be delegated to another circle. Please see Delegate to another Circle for more details about delegation.

Some of the epic/story information may differ depending on whether the epic/story is opened in the circle “delegated from” or the circle “delegated to”. This is e.g. the case for value estimates and release planning.

If you have delegated a story to another circle, you can see the release planning and estimation info from the view of the circle delegated to. It may differ from the release planning in the current circle. 

Moving an epic/story to another circle will completely remove it from the current circle and create an identical one in the selected circle. The circle it can be moved to is determined by whether the current circle has relation to that circle. See Circle Map for more info on this relation.

A simple form for terminating delegation to Jira where a Story is disconnected from the corresponding Jira Issue that was created, has been implemented. All Jira properties on story will consequently be cleared from after this operation.This can be done from the Story menu in Agemba and will result in the Jira Issue summary(title) being prefixed with [UNDELEGATED].

NB: General information about Agemba-Jira integration can accessed here. 

You can create an epic or a story in one circle (e.g. a customer circle) with the initial user story and then delegate the epic/story to another circle (e.g. a primary circle) for further refinement and implementation. The team in the customer circle will still be able to follow the state of the epic.

In the Circle Map the links between circles define, to which circles the epics/stories can be delegated.

The epic/story seen from both circles

The state, title, user story and description will always be the same seen from both circles. If e.g the user story is modified by the team in one of the circles, the other team sees the changes as well.

Users from both circles can enter epic comments, and the comments can be read and replied to by both teams.

The delegated epic can, however, be assigned to different releases in the two circles. It can have different assignment to user/team and it can have different value and effort estimates.

Activity logging for when delegating, cancelling delegation and changes is also done across both circles for the delegated entities.

What you can do with the epic/story in the customer circle

The team in the customer circle will usually enter the user story text before the epic/story is delegated to a primary circle. They may also place the epic/story in a release to indicate the expected deadline. And they could enter value estimates for the epic/story.

When the epic/story has been delegated, the team in the customer circle can still follow the state of the epic/story. A user with manager rights is able to change the user story and description, but will usually not do this, as they have handed over the epic/story to the primary circle team.

If the epic had child stories or epics, these are moved to the circle delegated to. They are not visible anymore in the customer circle, and it is not possible to create new stories or epics below the delegated epic.

The epic/story can be planned to a release if needed but not to a sprint. This limitation is based on the theory that any delegated work will be tactically implemented in the destination circle.

Attachments can be added to, edited and also deleted from the epic/story and this will be reflected in the primary circle.

What you can do with the epic/story in the primary circle

When the epic/story has been delegated to the primary circle, this is where it is handled from now on.

Any stories or epics below the delegated epic are moved to this circle. The team can add more child stories and place these in sprints for implementation.

Attachments can be added to, edited and also deleted from the epic/story and this will be reflected in the customer circle.

Cancelling delegation on an epic/story will completely remove it from the circle that it’s delegated to terminating the delegation process. Thus, this can only be done from the circle where the epic/story is delegated to. The epic/story that was delegated will also be removed and replaced with the epic/story from the circle it was delegated to, only with its state reset to created.

All activities that are related to the user currently logged in. It is possible to navigate and see older or newer pages by scrolling to the bottom of the dashlet. Most of the logs will include a hyperlink to the overview of entity the log is about, to the right of the row the log is shown e.g

Select any of these filtered lists from the dropdown menu as shown in screenshot below:

Most of the logs will include a hyperlink to the overview of entity the log is about, to the right of the row the log is shown e.g

Licenses are configurable at the Site level and in the present state only system administrators can do this. Currently, the available licenses are:

Limited – with this license one can assign Limited Site role to users and Limited Circle role to teams and users. Generally gives limited viewing rights to the users with the role. See Site roles and Circle roles for more explanation. 

Standard – with this license one can assign Ordinary Site role to users and Ordinary and Manager Circle roles to teams and users. See Site roles and Circle roles for more explanation. 

Admin –  with this license one can assign Site Administrator role to users and as the name suggests, the role gives overall rights for managing the Site.

The teams shown include those in all the Circles across the Site that the user is a member of.

See more on Teams in Agemba here.

Circle roles can be assigned to teams and users in Agemba based on the licenses setup. Even though it is possible to setup roles per user, it is highly recommended to create teams, add users and then assign roles to the teams. See more on teams here. In this way it is also easier to assign work and mention users in comments by simply using the team name.

A user role consumes a license quota in that Site even in the case where there are several Circles within the same Site and users are shared. The following Circle roles are available:

Limited User – this role requires the Limited license (Read more). User with this role whether directly or indirectly via team membership, has most most of the viewing rights and very limited editing rights for work assigned to them. Adding attachments to the work assigned to them and general commenting is also permitted for users with this role. This role does not permit altering of the state of epics and stories i.e setting them to ready, in progress and so on.

Ordinary User – this role requires the Standard license (Read more). Like the Limited role, this role gives viewing right to the user but more extensively. The user with this role has also extensive editing rights. This role also allows for users to start and end work on epics and stories i.e set to ready, in progress and done. It however does not permit the actions that affect the preparation, delegation and termination of epics and stories.

Manager – this role requires the Standard license (Read more). It permits every possible action within the circle apart from deleting the comments of others. In Scrum, this role is synonymous with that of a product owner.

Site roles can be assigned to users in Agemba based on the license modules enabled and the subsequent quotas for the roles. The following Site roles are available:

Limited Site User – users with this role have overall viewing rights for the site but no editing rights. Besides, they will have access only to Circles that they have Limited role in, see more about Limited Circle User role here.

Ordinary Site User – users with this role have overall viewing rights for the site but no editing rights. However in contrast to the Limited User, they will have access and overall viewing rights to Circles in that site regardless of whether they have Circle roles or not. See more about Ordinary Circle User role here.

Site Administration – just as the name suggests, the users with this role will have overall viewing and also editing rights for the Site and also all its Circles.

The “Heap” is meant to contain impediments epics/stories that need to be implemented but do not necessarily need to be functionally placed into the Storymap tree structure. See details here.

“Inbox” is specifically meant to contain newly created epics/stories (outside of the Storymap or from its menu) and also newly delegated epics/stories that are yet to be functionally placed into the rest of the Storymap tree structure. See details here.

The “Heap” is meant to contain epics/stories that need to implemented but does not necessarily need to be functionally placed into the Storymap tree structure. See more details here.

“Inbox” is specifically meant to contain newly created Improvement epics/stories from its menu that are yet to be functionally placed into the rest of the Storymap tree structure. See details here.

“Inbox” and ”Heap” subsections exist in the “What” section and in all the sub-categories of the “Why” section.

“Inbox” is specifically meant to contain newly created (outside of the Storymap or from its menu) and also newly delegated work, that is yet to be functionally placed into the rest of the Storymap tree structure; somewhat like the function of the inbox in emailing services. It is therefore not possible to start any actual execution of the work while it is here and any attempt to set work into progress etc. will automatically move it to the “Heap”. Note that it is not possible to manually put any work, created elsewhere, here.

The “Heap” is meant to contain work that needs to implemented but does not necessarily need to be functionally placed into the Storymap tree structure. As a consequence, parent-child relations are not supported while working here. The work here can at anytime be moved to the rest of the Storymap structure and vice versa. 

The “Heap” is meant to contain Improvement epics/stories that need to implemented but do not necessarily need to be functionally placed into the Storymap tree structure. See details here.

“Inbox” is specifically meant to contain newly created impediments epics/stories from its menu that are yet to be functionally placed into the rest of the Storymap tree structure. See details here.

The “Heap” is meant to contain Issue epics/stories that need to be implemented but do not necessarily need to be functionally placed into the Storymap tree structure. See details here.

“Inbox” is specifically meant to contain newly created Idea epics/stories (outside of the Storymap or from its menu) that are yet to be functionally placed into the rest of the Storymap tree structure. See details here.

The “Heap” is meant to contain Idea epics/stories that need to be implemented but do not necessarily need to be functionally placed into the Storymap tree structure. See details here.

“Inbox” is specifically meant to contain newly created Issue epics/stories (outside of the Storymap or from its menu) and also newly delegated Issue epics/stories that are yet to be functionally placed into the rest of the Storymap tree structure. See details here.

A theme should ideally be used when the item (either a story or an infrastructure) to be added to the Storymap is in its broadest form. For instance in a website implementation project example, the item webshop could be a theme since it can further be broken down to items such as Delivery or Shopping basket. Such children of a theme can either be epics or stories depending on whether they need further breaking down. Note that the Storymap constrains one to start with theme(s) and from there further break down to epics/stories if necessary.

A Preplanned list is a container that is meant to be used to contain an ordered list of product backlog items that (by Scrum definitions) are yet to be planned. Preplanning stories/epics is to obtain an early grouping of items for a future release.

It becomes very relevant when working in the Product Backlog and you want to “empty” the list of unplanned items in the left pane, and organize these items without having a specific release date. Once the epics/stories are ready to be planned, they can be individually moved to the desired Release or Sprint.

Welcome to Agemba

Since you have access to multiple sites, you first need to select a site using the site selection dropdown in the top menu. 

You can read more about using agemba here.

An invited user can be given direct roles (as opposed to team membership) in order to obtain user rights

If the user is being invited to join a Circle and they already exist in the Site, their email will be listed once the text field is clicked. Otherwise, any new emails can just be typed in.

Users will always be added to a Site even when they are invited to join a Circle.

Select if the invited user should be a member of the any teams and thereby obtain his user rights from these teams

When creating a new circle you can choose whether you want to be added as managing user in this circle or not. If you intend to add another user as circle manager after creating the circle, you can deselect this option.

As a Site Administrator you will still be able to access a circle, which you are not explicitly a user in, including editing users. But you have to be a managing user to create stories etc in the circle. You can at anytime add yourself as a user to any circle in your site.

In the trash bin you can see a list of all the trashed data. You can filter this data using columns filters or free text search.

It is possible to restore deleted data by selecting Restore from trash bin in the right click menu and choosing where to restore the data (its original position is suggested as default):

A Sprint is a container of a set of Items for delivery that have been agreed to during Sprint planning by the Team and the PO.

It typically has three states for an Item: “To do”, “In Progress” and “Done”. Sprints are executed one after the other (1-4 weeks length).

Items or cards exist in lanes within a Sprint lane. Each of these lanes can be reordered by dragging the grab menu at the beginning of the lane in the To Do column.

Tasks can be created directly in the lane a Story is in, using the icon.

This is the container that represents a Preplanned list.

Items, which primarily include Stories of the different available types, can be added via drag and drop from Releases, Sprints, Kanban lane and generally the left pane.

Once items are added to a Preplanned list, they can be removed using the option Remove from Preplanned list in their context menus. The items can also be dragged out.

This is a container for Kanban. 

Items, which primarily include Stories of the different available types, can be added via drag and drop from Preplanned lists, Releases, Spints and generally the left pane.

Once items are added to a Kanban lane, they can be removed using the option Remove from kanban lane in their context menus. 

A Kanban lane is a workflow line consisting of sub-states (sub-queues) each with their own done-criteria and each serving as the input queue for the next state.

By default it is comes preconfigured with three substates i.e. “To Do” , “Progess” and “Done”. The user can however configure each lane independently to contain more sub-states and in any particular order from the lane’s context menu.

Part of the configuration includes setting a wip limit, max number of items, per sub-state. This wip limit will then be shown on the Kanban lane card in brackets along with the number of Items currently in the sub-state. If the current number of items in the sub-state exceeds the wip limit, the wip limit will turn red. See screen dump below:

Tasks can be created directly in the lane a Story is in, using the icon.

A Sprint is a container of a set of Items for delivery that have been agreed to during Sprint planning by the Team and the PO.

Add and remove Stories

Items, which primarily include Stories of the different available types, can be added via drag and drop from Preplanned lists, Kanban lane, Release and generally the left pane.

Once items are added to a Sprint, they can be removed using the option Remove from sprint in their context menus. The items can also be dragged out.

Start and close a Sprint

A Sprint can be started from its context menu when it is considered ready. And similarly, the Sprint can be closed when all its Stories are done and will no longer be visible in this view. Consequently, all the Stories will be closed together with the Sprint unless for the special case where the Story was delegated to another Circle.

This is the container that represents a Release 

Add and remove Epics and Stories

Items, which primarily include Epics and Stories of different types, can be added via drag and drop from Preplanned lists, Kanban lane, Sprint and generally the left pane. The same items can be reordered while in the Release. Once items are added to a Release, they can be removed using the option Remove from release in their context menus.

Sprints can be added to the Release from the Release’s context menu. The items can also be dragged out.

Activate a release

Once a Release is ready start working with, it can be activated from its context menu too. The opposite is also possible.

Kanban lane configuration allows for 3 main actions i.e. 

1. Adding columns (sub-states) to the lane.
2. Adjusting the wip limit (max number of items) per column.
3. Except for the To Do and Done columns, reordering of the columns. Beware if there are any items currently in any of the lanes, they will consequently be moved to the To Do column.

In the left pane of the Product Backlog window you can see the stories, epics etc. from the Storymap Tree, which have not yet been planned for a release or sprint. It is possible to drag each of these from the left pane to a release or sprint in the main pane. 

You can filter the list and have different orderings. For instance, you can show the ready epics/stories with the highest business value at the top.

The title, business value estimate and effort time are shown on the entity cards to get an easy overview.

Detailed Planning of Epic Contents

In the early draft planning of a release, you will often add epics to the release.

When you are ready to add the epics’ stories to sprints, select “Show in Product backlog input” from the epic cards’ menu. The epic and its children are then shown as a tree in the left pane. You can now drag individual stories to sprints.

Note than only stories, ideas and issues can be added to sprints – not epics.

Also note that all the epics’ children are shown – including stories and epics, which are already placed in a release. In the other lists only unplanned items were shown.

In the left pane of the Sprint Backlog window you can see the stories, epics etc. from the Storymap Tree, which have not yet been planned for a release or sprint. It is possible to drag each of these from the left pane to a release or sprint in the main pane. 

You can filter the list and have different orderings. For instance, you can show the ready epics/stories with the highest business value at the top.

The title, business value estimate and effort time are shown on the entity cards to get an easy overview.

Detailed Planning of Epic Contents

In the early draft planning of a release, you will often add epics to the release.

When you are ready to add the epics’ stories to sprints, select “Show in Product backlog input” from the epic cards’ menu. The epic and its children are then shown as a tree in the left pane. You can now drag individual stories to sprints.

Note than only stories, ideas and issues can be added to sprints – not epics.

Also note that all the epics’ children are shown – including stories and epics, which are already placed in a release. In the other lists only unplanned items were shown.

Checking this box will disable the possibility of dragging this item from its current position on the Roadmap.
To re-enable dragging, simply uncheck and save the change.

Using the rich text editor you can format your text (e.g. a user story or detailed description) as you desire. Most of the format options displayed in the menu are well-known such as bold, italics, underline plus bulleted and numbered lists. For the advanced user you can edit the HTML directly in Source mode.

Inserting file references and images

You can upload attachments and insert references to them or (for images) display them inline. Simply click the image menu or the paperclip menu – or drag and drop your file into the editor. Inserted files/images will automatically be uploaded as attachments – and you can always insert/reference previously uploaded attachments.

References other stories or users

You can reference another story (or any other item with an ID) by writing # and start typing the title or ID. The editor will then suggest which item you want to insert a reference to. This reference will become a link to the item. Likewise, users and teams can be referenced by writing @ (however, this does not imply that the user is required to read the text as in comments).

You can write your comment using the rich text editor. See a more general description of the editor here, including how to reference files, insert images and reference other stories. You can read more about comments in general here.

Mentioning users

In comments you can mention users and teams by writing @and start typing the name/username of the user/team. By mentioning a user you thereby require that the user confirms that he has read the comment – and he will be notified about your comment in Agemba and by email. Likewise, if you mention a team, either one team member or all team members (depending on the settings of that team) will be required to confirm having read the comment.

This is a list of the users that have been assigned roles in the Circle. To see how users are added to Circle and assigned roles in that Circle, take a look at the videos below:

This is a list of all the teams that are in a Circle. The video below shows how teams are created, users added to the teams and roles assigned to teams.

The selectors here provide a way to plan to Releases, Sprints, Kanban or to Preplan.

Mutually Exclusive Planning Fields

Note that some of the selection fields are mutually exclusive. Preplanning is an early grouping of items for a future release, so an epic is typically moved from a preplanning container to a release during the release planning. It cannot be both preplanned and planned to a release at the same time.

Sprints are within releases, so planning a story to a sprint will automatically add it to the containing release as well (if it is not already in the release). A story cannot be in both a sprint and a kanban lane at the same time, as these are alternative ways to schedule a story implementation. The story can, however, be in both a release and a kanban lane.

Direct or Indirect Planning

“Direct” planning means that the epic/story is actively planned to a Release, Sprint, Kanban or Preplanned. E.g. by dragging the epic/story into a container in Product Backlog or by editing the planning fields in the epic/story’s “Edit Details” tab.

“Indirect” planning means that the epic/story is indirectly part of a release, e.g. because a parent epic or all the children are planned to the release. You can see if the epic/story is indirectly planned to a release in the epic/story overview.

Edit Warnings

If you e.g. remove an epic from a release by adding it to a preplanning container in the edit form, a warning will be displayed. This is only for your information, you are allowed to do this. The warnings only relates to direct planning, not indirect planning.

This region displays information about the delegation setup between the Circles i.e whether delegation is only possible one way or both ways. It also displays any items that have been delegated between the Circles. Clicking the delegated items will open a list of the same in the List View.

The manifest is a rich text field that can be used to for example state the purpose, terms and function of the delegation relationship between the Circles or for any other purposes. Files in the form of pictures, PDFs etc., can be attached to this region too.

This region displays any relationships that the entity has for instance delegation relationship for Circles.

This viewbox shows the deadlines for a story or epic.

A story or epic may have to meet more than one deadline date. The earliest deadline is called the Effective Deadline.

The effective deadline is show first. Below the separating line all the deadlines for the story or epic are shown.

Read more about Deadlines and Planning here

A Deadline is a date, where a story or epic needs to be finished. A Planned date is a date, where the story or epic is planned to be finished. If there is a conflict between the deadlines and the planned date, warnings will be shown on the story or epic.

Deadlines

A story or epic can have more deadlines. The earliest deadline is the Effective Deadline, i.e. the latest date where the story or epic needs to planned.

A story or epic can get deadlines in different ways. E.g.

• Link the story or epic to a milestone. You can link the story or epic to a milestone in e.g. Roadmap, Outline, Storymap or in the Relations Tab. The milestone has a deadline, which becomes a deadline on the story or epic linked to it.
• A release is a special kind of milestone (it is also a planning container). The release also has a deadline and you can link the story or epic to a release milestone in Roadmap etc as mentioned above. You can also add a release deadline to a story or epic by planning it in e.g. Product Backlog.
• In the Details Edit tab of the story or epic you can add a specific Required When date.
• If a parent in the storymap tree has an Effective Deadline, the child story or epic will inherit this date.

Planned Date

If a story or epic is planned to a release, its planned date is set to the release milestone. If a story is further planned to sprint, the sprint end date will instead become the planned date.

Preplanning will not set the planned date (preplanning containers have no dates). Adding a story to a kanban lane will also not set the planned date, but you can add the story to a release as well, which will set the date.

Warnings

If the planned date does not meet the deadline requirement of a story or epic or if the deadline is exceeded, warnings will be shown in the overview tab and on mouseover of the card.

A warning triangle is shown on the story or epic cards in the Storymap, Product Backlog pages etc.

In the Product Backlog left window (input window), you can get a list of all stories and epics with warnings. These can be sorted according to effective deadlines.

In this viewbox, you get an overview of the story, epic, sprint and release planning.

Planning

Stories and epics are usually planned by adding these to releases, sprints, preplanned lists or kanban lanes on the Product Backlog page (Read more).

A specific story or epic can also be planned via release etc. fields in the Edit Details tab of the story or epic modal window (Read more).

Planned Date and Warnings

Only epics and stories planned to a release or sprint, has a planned date. The planning date must meet the effective deadline, otherwise warnings are shown. 

Read more about Deadlines and Planned Date here.

Inviting Users

In order to add a user, you need to invite him first by writing his email address. The invited person then receives an email with a link, which he must activate to confirm the invitation and create his user account.

The invite information only includes the users email address, so no personal information as for instance name and phone number is added in Agemba before the user himself chooses to enter this information.

User Roles and Teams

A user can have different roles and thereby have acces to view, edit or perform different tasks. When you invite a user, you specify, which role (Limited User, Ordinary User or Manager) the user will have. You can also assign him to one or more teams in the circle, whereby he will indirectly get a role. Read more about circle roles or site roles.

You can change the role and teams for existing users.

How to see and add Users?

Select “Manage Users” from “More” in the Main Menu.

User Roles and Teams

A user can have different roles and thereby have acces to view, edit or perform different tasks. When you invite a user, you specify, which role (Limited User, Ordinary User or Manager) the user will have. You can also assign him to one or more teams in the circle, whereby he will indirectly get a role. Read more about circle roles or site roles.

You can change the role and teams for existing users.

How to see and add Users?

Select “Manage Users” from “More” in the Main Menu.

Assigning Stories and Mentioning Users

Users in a Circle can be assigned Stories and also mentioned in comments and descriptions in general.
The users will then be notified via email if they have not logged into Agemba to see the assignment or 
mention.
While this is possible, it is recommended to add users to teams and then assign or mention
the team.

Overview Tab

In this tab you get a read-only overview of the basic user details as well as the site roles and circle roles of the user.

Edit Details

In the “Edit Details” tab you can edit the basic user details and add a profile image. These details will then be visible to other users on the site.

When you finish editing the information, you need to press one of the “Save” buttons at the top of the tab. If you don’t want to save your changes, you need to press “Discard” before you can close the modal window.

Users Tab

In this tab you can see a list of all users and their details. By right-clicking on a row in the list, you can edit the user rights or remove a user.

You can invite new users by clicking the “Invite new user” button (read more about inviting users here). 

Inviting Users

In order to add a user, you need to invite him first by writing his email address. The invited person then receives an email with a link, which he must activate to confirm the invitation and create his user account.

The invite information only includes the users email address, so no personal information as for instance name and phone number is added in Agemba before the user himself chooses to enter this information.

User Roles and Teams

A user can have different roles and thereby have acces to view, edit or perform different tasks. When you invite a user, you specify, which role (Limited User, Ordinary User or Manager) the user will have. You can also assign him to one or more teams in the circle, whereby he will indirectly get a role. Read more about circle roles or site roles.

Show epic/story in left pane as a tree with children and dependencies. Detail plan the stories from the left pane by dragging stories to sprints.

Teams Tab

In this tab you can see a list of all teams in the circle and their circle roles. New teams can be created and by right-clicking on a row in the list, you can edit the existing teams.

Read more about teams here.

In this tab you can edit the view and edit rights of users. A user can be given different roles or be assigned to one or more teams in the circle, whereby he will indirectly get a role. Read more about circle roles or site roles.

Deleting will remove the item and put it in the trash. Deleted items can be restored

The “Required When” date is an option to set a specific deadline for when the story or issue is required to be completed. It can be seen as the When part of the user story.

To obtain a more detailed picture of a given deadline, a milestone should be created and linked to the story instead. 

If a Required When date is set, this will be included in deriving the effective deadline.The planning date must meet the effective deadline, otherwise warnings are shown. 

Read more about Deadlines and Planned Date here.

Go to Product Backlog and show this entity in left pane.

The impact maps gives a quick overview of all the relations and planning of a story or other item. The card and its position in the storymap hierarchy is overlayed to show all relations next to the selected card.

Welcome to Agemba

The tools Agemba offers will help you get a top-down overview of your agile projects. It assists you in the process from the first high-level draft planning to the refinement into smaller manageable tasks in the sprint backlog.

The Storymap Tree (Read More)

Most data entities in Agemba are organised in the Storymap Tree. The tree structure makes it possible to start from the top and add more fine-grained details later in the process.

Different Perspectives

Agemba has different views on the data to be used for different user perspectives.

One perspective is the product way to look at data. “Which functionalities do we want to include and what are the user stories for these?”

Another perspective is to focus on timelines and activities. “How do we reach our goals and in which order?”

How to get started?

1. Get to know the Main Menu (Read More).
2. Create Circles  (aka projects) and relations between Circles (Read  More).
3. Create Teams (Read More) and invite Users (Read More).
4. Initiate the high-level planning in Roadmap (Read More).
5. Break down your project in the Storymap and work with refining user stories (Read More).
6. Planning of Releases and Sprints in Product Backlog (Read More).

Product Backlog vs. Storymap Tree

In Agemba all data is organised in the Storymap Tree. This gives you the possibility to enter user stories at different levels in the Storymap and Outline views.

In Scrum terminology, the Product Backlog is an ordered list of everything that is known to be needed in the product. Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

In Agemba you can refine and add details in different views (Storymap, Outline etc.). In all views you can open a modal window for an entity (theme, epic etc) by double-clicking on an item. In the entity’s modal window, you can enter the user story and set business value estimates and effort time. If the entity can have children, you can add these.

Welcome to Agemba – Freebie Version

The Agemba tools will help you get a top-down overview of your agile projects. It assists you in the process from the first high-level draft planning to the refinement into smaller manageable tasks in the sprint backlog.

The Storymap Tree (Read More)

Most data entities in Agemba are organised in the Storymap Tree. The tree structure makes it possible to start from the top and add more fine-grained details later in the process.

Different Perspectives

Agemba has different views on the data to be used for different user perspectives.

One perspective is the product way to look at data. “Which functionalities do we want to include and what are the user stories for these?”

Another perspective is to focus on timelines and activities. “How do we reach our goals and in which order?”

How to get started?

1. Get to know the Main Menu (Read More).
2. Break down your project in the Storymap (Read More).
3. Initiate the high-level planning in Roadmap (Read More).
4. Planning Releases in the Product Backlog (Read More).

Extended functionality in FULL Version?

In the freebie version you can work with a single project (aka circle) and invite a limited . In the full version of agemba you have the extended functionality:

1. Create multiple Agemba Circles and relations between Circles (Read  More). 
2. Create Teams (Read More) and invite more Users (Read More).
3. Work with issue and idea tracking
4. More detailed planning in sprints

To update to a full version please contact the support team

Convert entity to story.

Description of issue

Description of task

Description of improvement

Description of impediment

Convert this entity to an Epic.

Convert this entity to an Infrastructure Story.

Convert to Infrastructure Epic.

Convert to idea.

Convert to Idea Epic.

Convert to issue.

Convert to issue epic.

Story with jira Issue

This story has been delegated to a Jira project. It means that a Jira Issue with the title and a merge of the userstory and description from this story has been created in Jira.

NB: General information about Agemba-Jira integration can accessed here. 

The Delegation Status shows the status of the sync process of the Agemba story with the corresponding Jira Issue. Delegation Status can be:

• Pending – Indicates that the delegation process i.e creation of a corresponding Jira Issue for the Agemba story  is not yet complete.
  NB: This status should not be interpreted to mean that the process failed or succeeded.
• Synced – Indicates that syncing with corresponding Jira Issue is active and the state of the Agemba story will be in sync with the status of the corresponding Jira Issue.
• Syncing Failed – Indicates that syncing failed and the Agemba story will not be in sync with the corresponding Jira Issue.
• Unsynced– Indicates that syncing between the Agemba story and the corresponding Jira Issue was deliberately stopped by the system, either because it was determined as completed i.e set to ‘Closed’ during syncing or as a consequence of canceling Circle syncing with Jira project altogether.
• Unknown Jira Status – Indicates that mapping of the Agemba story’s state to the read status of the corresponding  Jira Issue failed. The reason could very likely be that the JIra Status Map configuration on the Circle level was not setup correctly.
• Corrupted – Indicates that either the delegation or syncing process of the Agemba story failed because its data was corrupted.
• Uknown – Indicates that the system encountered a situation that was not anticipated during either delegation or syncing of the Agemba story.

Change of state

Change of state to e.g. “In Progress”, “Done” etc. must now be handled in Jira. The state of the Agemba story is updated accordingly by the system based on the Jira Status Map configured as part of Jira configuration at the Circle level.

Delegating an Agemba Story to Jira will result in the creation of a Jira Issue with a similar title and description composing of a merge of the user story and detailed description in Jira. Editing of the Agemba Story will consequently be restricted and its state, title and Jira description will be in-sync with that of the corresponding Jira Issue. Information about the Jira Issue will be made visible on the Story including the status of the delegation process. See details about the delegation status here.

NB: General information about Agemba-Jira integration can accessed here. 

Delegated source contents

The user story should describe the requirement from the user perspective .

The Detailed Description is for further explanations and details.

Go to Sprint Backlog and show entity in left pane.

Find and highlight this entity.