CRITERIOS ESPECÍFICOS DE TODOS LOS INSTRUMENTOS

Release planning meetings happen specifically to plan downstream delivery. If releases are occurring regularly, with a cadence of, say, bi-weekly, then it makes sense to schedule the release planning activity to take place regularly. This reduces the coordination cost of holding the meeting and ensures that everyone who needs to attend will have the time available.

The person responsible for coordinating the delivery, usually a project manager, typically leads release planning meetings. Any other interested parties should be invited: This usually includes configuration management specialists; systems operation and network specialists; developers; testers; business analysts; and for all of these individual contributors, their immediate supervisors or managers. Specialists are present for their technical knowledge and risk-assessment capabilities. Managers are present so that decisions can be made.

A mature organization will have a checklist or framework for a release that facilitates planning. Some of the things to be considered are the following.

Which items in the system are (or will be) ready for release?

What is required to actually release each item to production?

What testing will be required post-release to validate the integrity of production systems?

What risks are involved?

How are these risks being mitigated? What contingency plans are required?

Who needs to be involved in the release and present during the push to production (or other delivery mechanism)?

How long will the release take? What other logistics will be involved?

The outcome should be a completed template representing a release plan. With teams that are particularly sophisticated, I have seen the release scripted as an orchestration of procedures to be executed in a given order.

In a large meeting, completing the release plan may not be possible, and some independent follow-up work may be required on the project manager’s part.

Triage

Triage is a term borrowed from the medical profession; it refers to the practice of assessing and classifying emergency patients into categories for priority of attention. The system was first used in battlefield medical units, where patients were separated into three categories:

beyond help and likely to die soon, likely to live only if given immediate treatment, and likely to survive without immediate treatment. Emergency rooms now use a similar system to prioritize patients as they arrive for treatment.

Triage was adopted into software development for classifying defects (bugs) during the stabilization phase of a traditional software project. Triage is used to classify bugs that will be fixed, and their priority, versus bugs that will not be fixed and will be allowed to escape into production when the product is released. A typical defect triage involves a test lead, a test supervisor or manager, a development lead, a development supervisor or manager, and a product owner.

With Kanban it still makes sense to triage defects. However, the most useful application of triage is to the backlog of items waiting to enter the system.

Backlog triage should be held at relatively infrequent intervals. (Note: some Agile software development methods refer to this as “backlog grooming.”) Monthly, quarterly, and twice-yearly are intervals that are popular with teams. The attendees at a backlog triage will typically be the same product owners or business representatives who attend the queue replenishment meeting, along with the project manager. The technical people typically do not attend in such large numbers. Perhaps one technical- function middle manager will be present.

The purpose of a backlog triage is to go through each item on the backlog and decide whether it should remain in the backlog or be deleted. It is not to stack rank or provide

any prioritization beyond the simple keep-or-delete choice. Some teams have avoided the need for triage through automation and policy. The Microsoft XIT team from the chapter 4 case study would delete any item older than six months at a regular monthly interval. The reasoning was that if an item had not been selected for the input queue in six months, it was unlikely to be of significant value and therefore unlikely ever to be selected. If this changed, it was also likely that it would be requested again and hence nothing was lost by deleting it from the backlog.

The purpose of triaging the backlog is to reduce its size. The benefit of a smaller backlog is that it facilitates easier prioritization discussions. If there are 200 items in a backlog, it will take significantly less time to pick winners at a prioritization meeting than if there are 2,000 items in the backlog.

A good rule of thumb might be that if the backlog exceeds three months’ worth of work, that is, three months of delivery throughput, and all the items in the backlog cannot enter the system within that time, it would be a good idea to prune the backlog. The appropriate size of the backlog will vary according to different markets and domains. Domains with high volatility will want a backlog sized to perhaps one month’s worth of items. Domains with very low volatility might be able to hold a backlog with up to one year of items.

Hence, there is a relationship between the size of the backlog, the volatility of the domain in which the individual kanban system is operating, and the delivery velocity, or

throughput, of the team. If a team delivers 20 user stories per month and the domain has some, but not excessive, volatility, so that a three-month backlog is desirable, the backlog should have approximately 60 items.