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.

Users

A user is a person with a login to the Agemba product. 

Inviting Users

In order to add a user, you need to invite the user. The user then gets an email with a link, which he must activate to confirm the invitation and enter his user information.

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

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. The user can get roles via the teams.

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.

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 finish, before it can be closed.

Relations from “Who” area

• Contributes Relation
• Interest Relation

How to see a relation in Agemba

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 see and make comments to the entity. 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. It only includes the top of the list, but if you start writing the name or initials, it will narrow the list to the names matching your input. Select the user or team, you want to address.

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 Story Map 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
• Road Map
• Outline
• Story Map
• 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 Card

A sprint is a time-box of one month or less during 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 >.

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

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.

How to add Relations?

At the top of the “Relations” tab you see an input field. If you want to create a new relation from the current entity, start typing the id or title of the entity, to which you want to create a relation.

A selection list with items matching your input so far will appear below the input field. The matching entities are grouped in the different relation types. Select the entity, you want to create the relation for.

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 definition, are yet to be planned. 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. 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.

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 

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.

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 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.

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 format the text 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.

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. Planning to a Sprint will automatically select the Release the Sprint is in. Planning to Kanban will reset any link to a Sprint and Preplan while preplanning will reset all planning links.

This region displays any planning information of the current entity. Which can be what Release, Sprint, Kanban it is planned to as well when it is Preplanned.

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.

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.