🤦 🤦 🤦 Combodo's customers only 😎 😎 😎

Software development

• Manage the Software products and versions which you are developing.
• Managing Development projects through Sprints and User stories (Features and Bugs).
• Handling Backlog review, Sprint Review and user story life cycle based on Agile developments
• Supporting your software, by tracking your customer requests down to each User story, so their prioritization and scheduling can maximize your customers satisfaction.

Release management

• Use Release Ticket when you want
  • to publish as a software editor a new version
  • to move to production a new product version on your environment or one of your customers
  • to deploy a process or an infrastructure on a customer environment
• Use Template tasks for each category of release that your company run through. Those tasks will be automatically cloned on each Release Ticket of this category. Thus ensuring that no tasks are forgotten, owner are defined and tasks progress are tracked.

Not compatible with iTop versions below 3.0.0

• iTop Professional 3.0+ or Essential 3.0+ with extension: Hyperlinks configurator and extension: Kanban Board
• Recommended: iTop Professional 3.1.1+ with extension: Kanban Board

Use the Standard installation process for this extension.

• If you have modified the UserRequest, Incident or Problem presentation, you might need to add the field releasetickets_list to the presentation/details either with an extension in XML or with the ITSM Designer

This extension brings a few data which are loaded during the first installation. The data will be in French or German if it is the default language of your iTop, otherwise in English.

• User story categories, a Typology sub-class, with entries like: Bug, Enhancement, Regression,…
• User story domains, which define tagset values, to tag your user stories by domains.
• Release categories, a dedicated class, to prepare template tasks for the Release Ticket. A few examples are loaded, one with a some template tasks

It also brinks new profiles named Release Agent, Product Owner and Release Manager to be used in addition of the standard iTop profiles

The extension has just one configuration parameter, handling the default duration of a Sprint

Configuration

    'combodo-release-mgmt' => array(
        'default_sprint_duration' => 14, //days
    ),

The extension is adding, at installation time, entries to the list of rules defined for the User actions configurator extension and for the Hyperlink Configurator extension if you have installed them. Those entries are available to users based on profiles brought by this extension.

Check your configuration for the new entries and adapt them if required. Q&A section contains default rules

New profiles are brought by the extension. You need to give them to your users according to the role they must play in the Release management process

• Release Agent can:
  • Create User stories and handle their lifecycle for the transitions under a developer responsibility (all but “Close”, “Re-open” and both “Rework…”)
  • Create Sprints and manage them throughout their life cycle
  • Handle Release Tasks throughout their lifecycle
• Product Owner can:
  • Create Product and Version
  • Create User stories and handle their lifecycle for the transitions under a product owner responsibility (all transitions but “Start work” and “Request acceptance test”)
  • Create release project and Sprints and manage them throughout their life cycle
  • Handle Release Tasks throughout their lifecycle
• Release Manager can:
  • Create Release Categories and Template Tasks
  • Create Release Tickets and manage them throughout their life cycle
  • Create Release Tasks and manage them throughout their lifecycle

This extension can be used for two different processes: developing software products and releasing them. You can use them together or independently.

• In all cases, you will have to define Release Products and Product Versions.
• For Software development process, you can organize your development through Development Projects that are broken down into Sprints then into User stories which will be coded.
• For Release management, you identify the different sort of releases you do, and for each Release Category identify the Release Tasks that must be performed, who need to do them and so on… Then for each requested release, create a Release Ticket and handle it throughout the different steps of its life cycle.

The entry point for handling those 2 processes and their associated objects is a new group Menu: Development and Release

Unless you just want to release infrastructure or processes, you will have to identify and create the Software products and versions that you develop and/or deploy. For this, use the menu dashboard “Products and projects”. At this stage, you don't need to create projects yet.

A Product allow you to specify the different teams which contribute to this product:

• PO team and Product Owner: the Product Owner(s), who are defining the acceptance criteria of each User stories and testing them based on those criteria. The proposed Product owners are the members of the PO team.
• R&D team: contains the release agents, those who will code the user stories
• Support team: contains the persons supporting the customers using that product

Define the product versions of your products

• This object is simple, it has no lifecycle and no automation
• You can track manually the version status: Planned → Under development → Delivered → Obsolete
• You may define the previous version, when the development starts, when the build was made and even the build file.
• You can specify product that are bundle of other products, with the Sub-products tab.

Tip1: Get aligned in your organization on the status meaning, especially “Obsolete”, is it:

• “no customer running this version can call you”,
• “no fix will be provided, but you will assist them”
• “No new deployment must be planned with those obsolete versions”
• or any other mix…

Tip2: You may create manually some of your product versions and automate the creation of others directly from your building tool. This is the strategy used by Combodo, iTop futures versions are manually created while extensions versions are automatically synchronized once built by their factory.

Tip3: Combodo uses the Sub-products to specify which extension versions are included in an iTop product, such as the iTop Professional 3.1.1.

If you maintain / develop software products, this extension allows you to organize your development in Project, Sprint and User stories.

Release project allows to group together a set of shorter development cycles called Sprints.

• It can cover a single product version or several, but there is no formal relationship as the product version(s) may not yet exist.
• Give it a name that makes sense and cover this aspect.
• It is a simple object without any lifecycle nor automation.

On Kanban tab, you have a overview of related user stories and sprints by status and you can act on them.

A Sprint is a defined period of time during which a set of User stories are expected to be coded.

• During Sprint preparation, User stories from the Backlog are added to be done within that Sprint. Ensure that your development capacity named “Sprint velocity” exceed the “Required velocity” which is the estimated capacity to code all the user stories of this Sprint.
• While the Sprint is Running, developers code the different User stories.
• At the end of the period, during the Sprint review, User stories which have not been completed and tested successfully are either moved to the next Sprint or returned to the Backlog
• Then the sprint is closed.

An action is proposed on the sprint to create the next one, within the same project, organization, using the same velocity and scrum master, starting from the end of this one, with the default sprint duration and proposing you to change any field before creation.

During the sprint review, if there remain some user stories still open, then a message will warn you that those user stories should be moved into the next sprint (they can also manually be sent back to the backlog). If the next sprint is not created yet, that would be done automatically during the closing. The closing transition will tell you in its label, if a next sprint will be created or not and if user stories will be moved or not. If user stories are moved, this information is added to the sprint log.

A User story is the object to track every idea, issue and feedback about a product.

It's the most important object for the software development process with a rich lifecycle:

• Sandbox: After creation, user stories are in the sandbox, they are not yet qualified.
• Backlog: During the qualification, the owner specifies what is expected and how he will test that the results meet the expectations,
• To-Do: During the backlog review, the team identifies stories to do, for each estimates the development effort required and put them in a Sprint for development.
• In-progress: A developer will implement the user story in the code, specify the product versions in which it is included and move it to the test team
• Acceptance tests and Assigned to tester: A tester will then take it and act based on the result of that test
  • re-open because specifications need to be reworked → Backlog
  • re-open because acceptance criteria aren't met → To-do
  • close → Closed

Qualification → backlog Product owner fills the “definition of done” to describes what he is expecting to be available before the user story can be moved to “Acceptance tests”. Planning → todo During meeting with dev team, the user story is analyzed, quoted and attached to a sprint. Development → wip → In addition of all prompted fields, Developer must fill “Fixed in versions” tab, before asking for tests to indicate tester what to test. Tests → acceptance_test & assigned → After applying tests, feature will be closed or re-opened due to code incorrect or specifications to rework.

Tip: For eg. you could define new Categories Epic, Feature and create Epic user stories as parent of Feature user stories, themselves parent of Enhancement user stories.

On each sprint, we measure different velocities:

• Required velocity which automatically computed as the sum of points of all user stories of the sprint. If you update the points of a user story or you move a user story from one sprint to another, the required velocity will be automatically recalculated. This allows to know the resources needed on the sprint to developed all the planned user stories. If you don't have enough resources, either get some, remove some stories from the sprint or extend the sprint duration, but this last option is against agile logic.
• Sprint velocity is your capacity of development during the full sprint period, knowing the ressource available for that sprint. If you don't fill this field, the velocity of the product's development team will be used.
• Consumed velocity is automatically filled when a user story is closed and only then.

When the sprint reach its end date, it is expected to be closed regardless of its user stories status. All user stories which aren't closed yet must be transferred to another Sprint or send back to the Backlog.

You can move non closed user stories from one sprint to another, using one of the following options:

• When you close the sprint, specify the next sprint, and iTop will automatically move user stories not already closed from the current sprint into the next sprint.
• Or from the details screen of a Sprint, you can click on the menu Close this sprint, create new one, and move non closed user stories which does what's is name says, it create a new sprint, defines it as the next sprint of the current one, moves the non closed user stories from the current sprint to the new one and close the current sprint.

If you support and develop your product versions, then you will manage User request and User stories to track customers feedback,

• Clients will come back to you sometimes reporting application bugs or suggestion for enhancement. We will assume that they do this using iTop User Request, because that's the most efficient.
• Your Support Agent, from that User Request will create a User story object, in one action menu, copying the title and description.
• He will complete the User story with information such as the impacted Product and save it in the Sandbox, for Product Owner to handle it further.

The release management process can be used for different purpose:

• Deploying a new infrastructure, a new process or a new software version or even a combination of all those aspects.
• As an organization, you may handle different type of deployment, for your own benefit or the one of a customer.
• Each type of deployment requires a different set of tasks to be performed.

To address the above described situations and needs, the extension brings different objects:

• Release category: a typology to categorize the different type of deployment release that your organization manage
• Template task: represent tasks which must be performed for a given Release category.
• Release Ticket: a type of Ticket to manage a particular release, with a start date, an end date, different tasks and different states to go through
• Release task: the tasks of a Release ticket, automatically created based on the release category template tasks.

Start by defining the categories of deployment release that your company performs. The extension comes with a few categories, but feel free to rename them to match your business.

On each Release category, define the tasks to perform to achieve this type of release. The fields specified in the template tasks, will automatically feed the tasks which are created on true release ticket of this category. Information which can be prepared are:

• Name
• Description
• Parent task: which can be used to specify sub-tasks or to handle dependency: parent task needing to be completed before starting this one
• Team: who is in charge of doing the task
• Owner: member of the team in charge of doing the task
• Lead time (in days): this represent how many days before the release deployment date, this task must be started
• Duration: how many days the task will take to be completed

To handle a release, you will create a Release ticket.

• As most iTop tickets, you have an organization, a requestor, a status, a title, a description and a few release specific fields
• It can be used to publish product versions which have been build during a release project. Specifying a project, allows to automatically retrieve all the product versions impacted by the project, as well as all the tickets from customers (User requests, Incidents, Problems,…) which have lead to creation of User story, stories which were closed within this project.

Lifecycle will handle (among others)

1. ensure that a test plan and a rollback plan are defined
2. based on the type of release, ensure that the components to release (Software versions or CIs) are identified
3. get an approval before releasing
4. propose an earlier life support to monitor the release with more reactivity
5. then move to production which close the release ticket

You can define on each Release ticket, tasks which must be performed to achieve this particular release.

• Name
• Description
• Parent task: which can be used to specify sub-tasks or to handle dependency: parent task needing to be completed before starting this one
• Team: who is in charge of doing the task
• Owner: member of the team in charge of doing the task
• Reverse planing: this flag, let you decide if the task must keep fixed dates, or floating dates linked to the ticket deployment date
  • Yes: Start date and End date are automatically computed, don't change them, it's useless in that case, but set Lead time and Duration
  • No: Specify Start date and Duration but don't change Lead time and as it won't have any effect
• Lead time (in days): this represent how many days before the release deployment date, this task must be started
• Duration: how many days the task will take to be completed

Rather than creating each time all your tasks from scratch, if your process is mature and your tasks well identified, then document then as Template tasks of a Release Category and select this particular category when creating your Release Ticket. Then as soon as you plan your ticket, all the template tasks defined on the associated category, will be copied as Release Tasks on the Ticket. Their start and end dates will be automatically computed based on the Deployment date of the Ticket.

Accessible from the menu Release Tickets get an overview of your Releases, and as any dashboard customize it to your need.

Accessible from the menu Release Calendar get an overview of your Projects, Sprints, User stories and Releases

Q: In my company, the team which performs the tests is not the same as the team who specifies the User stories, how can I do?
A: On the ReleaseProduct class, add a new 1:n relation to the class Team, called test_team_id, add it to the Product presentation details.
Then modify the filter of the UserStory tester_id field, so it proposes members of that new team instead of po_team_id members:

SELECT Person AS p 
  JOIN lnkPersonToTeam AS l ON l.person_id=p.id 
  JOIN Team AS t  ON l.team_id=t.id 
  JOIN ReleaseProduct AS pd ON pd.test_team_id=t.id 
  WHERE pd.id =:this->product_id

Q: I want to be able to manage the Product version composition from the Bundle side, how can I do?
A: On the ProductVersion class, modify the presentation details: add the field parentversions_list

This is the second side of this reflexive relationship:

• productversions_list are the sub-versions
• parentversions_list are the aggregated-version.

Q: When a new sprint is created automatically at previous sprint closure, the new sprint has the same name, it's confusing, how can I do?
A: In the Designer, change the Sprint naming to add the number within the name, so they automatically become different and unique after a clone, as the number (iteration) is automatically incremented in a sprints chain.

Q: I have imported massively sprints and user stories from another tool, but my sprints required and consumed velocity are wrong, what can I do?
A: Ask an iTop administrator either to change the access write to an existing hyperlink configuration rule or to perform the action on the sprint

Q: Can I change the proposed action menus on Sprint, User story and Release Ticket?
A: Yes, by editing the configuration file. Those actions are defined in the hyperlinks-configurator and object-copier modules.

🚧: Add default rules