Implementation of the procedure “Planning Release Release by Product” by the tools of the Atlassian family

This is my report from the Moscow Atlassian User Group Meetup, dated March 1, 2017

Context and task

The company independently develops software (Products) for the needs of its business units (Customers). Some of the products are delivered to customers and the company is engaged in their refinement and development.

There is a general list of tasks for each of the products (Product Backlog). Every month there are new releases for some products.
')
The goal is to answer the question about which products you need to release releases and which client requests will be included in each of the releases.

The result is a development plan for the next production cycle (Sprint Backlog). List of releases for products to be released in the next cycle.

Business logic

Each product is assigned to a Product Owner. Each business unit is assigned to an IT-Business Partner (Client Manager). The client manager refers to the Product Manager with a possible development order (User Story). If the Product Manager’s “pain of the Customer” and the “requested tablet” are understandable, then he asks the Team Development Manager (Team Lead) an assessment of the feasibility of the option in the product and an approximate labor intensity. According to the results of the assessment, the Customer either confirms the placement of the order or refuses. This is how the list of requests for product development (Product Backlog) is formed.

The overall complexity of client requests for improvements exceeds the amount of available resources for their execution in the production cycle. In order to understand what requests need to be done first of all, every month the Product Manager calls on Client Managers to prioritize the list of requests by their Customers and indicate which ones they want to receive as a result of the next development cycle (Sprint). Thus, the first version of the development plan for the next cycle, consisting of requests noted by Client managers, appears.

Each product is also assigned to one of the development teams. The product manager requests from the Development Team Leader the available development clock for the future cycle (Sprint Capacity).

The product manager compares the complexity of the initial plan with the available command power. If the wishes of the Client Managers exceed the available resources, the Product Manager sifts the tasks through a sieve of profitability criteria for the Company. At the exit, the second version of the development plan with the most beneficial queries for the company with the complexity of implementing the appropriate power commands per cycle.

Requests within the plan are grouped by products (releases) and the order of their implementation within the release is set (re-prioritization). This tells the teams which requests to implement in which order. The resulting plan (Sprint Backlog) is communicated to the Client Managers and posted on the internal portal.

Technical implementation by the Atlassian product family

JIRA Sotware

Performs as a platform for the entire IT solution. Provides the implementation of the business function of keeping records of requests for the development and refinement of products.

Uses the standard JIRA features for adding custom fields (custom fields) for storing and further processing information on requests.

For planning, you will need to add the following fields:

Customer Priority
Data from the Feasibility Study: Expected income-savings
Data from the feasibility study: Payback period
A mark of desire to receive as a result of the next development cycle
Information on which development cycle the request is in

Which need to be displayed on the screen request: create, edit and view. This is done through the screens administration panel.
An example of the query editing screen with custom fields.

JExcel

As the name implies, it is a kind of Excel. This is a JIRA plugin that allows you to work with sample lists that are not in the basic functionality.

In this case, you will need two of its features:

Edit queries in JIRA without entering them
On one page, the Client Manager will see all his client requests, will be able to indicate to them the priority and which of them he wants to see in the next release.
Summation in columns and selected cells
The product manager will see the overall complexity of requests for the next sprint. Knowing how much resources he has, he scatters requests for development cycles, what will go into the closest one, and what is next.

The work tool in JExcel is a workbook, it is created based on JIRA projects or saved filters. Filters written in Jira Query Language (JQL) does not yet understand. No additional settings are needed.

There are two types: JExcel Lite - free, JExcel Pro - paid.
marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview
moresimp.com/jexcel-lite

Tempo planner

This is a JIRA plugin that provides opportunities for maintaining resources, detailed planning of their work and calculation of accessibility.

Allows you to plan sprint tasks for employees and days.

It takes into account holidays and working days, as well as the% availability of an employee in a team if he is not available at 100% for a certain period of time.

This plug-in is used by the Development Team Leader, based on his data, he provides product managers with information on the availability of resources for the next development cycle.

Plugin paid.

marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview
tempo.io/products/tempo-planner

Confluence

This is a standalone product - a platform that acts as an ecosystem for building an internal portal and a company's knowledge base. In the context of planning, it is used as a showcase for all who need up-to-date information about development plans for the next cycle and what happened in the past.

So on the page in Confluence looks Sprint Backlog and a plan for the release of releases for the month.

The standard macro is Jira Issue / Filter macro, which displays the saved filters in JIRA to Confluence. This is the screen settings display filter on the page.

It is designed so that when information is updated in JIRA it is updated in Confluence, so the plan page is also used to monitor the current status of the plan.

Confluence as JIRA is a paid product.

3 fundamental ideas for developing a planning process

Idea One

Usually the situation is as follows: There is a Product, a Team that makes it, a constantly growing List of product improvements (Product Backlog). It is replenished with Project managers, Sales managers / clients ... who need improvements on their projects / clients (User Story) within a certain period of time. Managers compete for resources and this leads to the fact that:

Option number 1: Priorities in the work of the team change regularly. The Manager goes to the Management and punch himself with a priority increase and the allocation of team resources for a certain period, until a more important project, order or more convincing Manager appears.
Option number 2: Everyone is distributed to a small piece of the team resource.

As a result, the team does not complete the work on one story, switches to the next. The release of a new product release is regularly postponed, because not one of the improvements is not ready.

The figure shows that we have 3 client stories, the complexity of each 1 month, makes them one development team. Because of the constant switching between the stories, there are additional switching costs, so all 3 stories are dealt with in the 4th month.

This figure says that if the stories are prioritized and consistently implemented, they will be implemented faster than in the previous way of organizing work. The green boxes at the top indicate revenue from customers for completed orders.

The resources of a particular team are better focused than spraying and until the first hare is caught, do not chase the second one.

Idea Two

The longer the product is developed, the higher the likelihood that customer requirements will have time to "rotten out" during this period, which leads to their actualization by the client, changing the technical specification, increasing the amount of work and again leads to lengthening the development period or increasing resource requirements to withstand time limit All this time, the Client works without our product, does not benefit from it, and the final cost of the product for him increases. The risk that the Client will not be satisfied with us and the product is growing.

So that the requirements are not “rotten” and the Client is satisfied, you need to produce a product for which the client is willing to pay as soon as possible. To do this, client requirements must be broken down into self-sufficient blocks. By releasing the first block and taking up the second, we give the client the opportunity: to gain experience in using the product and benefit from it, clarify the requirements for the third block and place an order for new requirements that the Client did not think about or did not know that they would be needed.

A release with one useful function for the Client in a month is better than a release with a dozen functions, but in six months or a year.

Idea Three

In addition to the cost of developing useful features, each release has conditionally fixed costs for its release: this is the release build, deployment of the test environment, regression testing ...

Imagine that we have 4 products and before that we released a new release for each product 1 time in half a year, our costs for releasing releases are equal to 4 conventional units. If we decide to release more often, for example, once a month, guided by the Idea No. 2, then our costs for the release of releases will become equal to 24 conventional units.

It follows that:

If earlier we had 1 unit of overhead on the release of one useful function, now it will have 6 units on it.
In order to ensure the release of 20 additional releases, additional resources will be required. Do we have them?

To reduce these costs, you need to implement DevOps tools.

When deciding on the frequency of release of releases, it is necessary to calculate how many releases per month we can physically release now and how the total cost of the developed product function will change.