The co-funded development pool

This page provides detailed guidance on how the development pool is managed. This includes how items are logged, prioritised, planned, and agreed, as well as how agencies and their staff can keep up with progress.

Contractual information about the co-funded development pool is in lead agency agreement - schedule 6, section 9. The main principle is that outputs from the pool are beneficial to a cross-section of participating agencies.

What can the pool be used for?

The agreement states that the co-funded development pool is designed to be spent on:

1. The development of new features, themes and templates.
2. Enhancements to the SilverStripe CMS.
3. Taking modules and themes developed by agencies and building them into the CWP offering.
4. Verifying modules developed by agencies, so that they can be reused with a higher degree of assurance.
5. Anything else that the lead agency agrees is beneficial to agencies.

How does any agency log something to the pool backlog?

New items are logged in the CWP workspace, in the library ‘Items for the backlog’. Items must be logged by an agency stack manager or relationship manager, to confirm that the agency wants the pool time to be allocated. Development and content staff need to liaise with their website’s stack manager to log items.

How can an agency keep up to date on progress?

Agency staff and their web services providers can keep up to date with progress in the CWP workspace in the government Shared Workspace. Each month a progress report will be loaded in the library: ‘Progress reports’. Every 3 months a summary report, prepared for the quarterly operational review board meeting, will be loaded into this library.

Agency staff are recommended to setup notifications in the CWP workspace so that they are alerted when new information is added.

How can developers view the pool backlog and progress?

Ask the stack manager to email the people’s names and their emails to online@dia.govt.nz, requesting access to the CWP workspace. Developers, including vendors, will be able to read information in the co-funded pool libraries, but not contribute. They won’t have access to the other libraries.

How does an agency take advantage of new features?

In general there are three ways:

1. SilverStripe will roll out a platform wide change for all agencies.
2. The fixes or new features will be in an upcoming recipe release. These releases occur every 3 months. 
3. A new module will be made available through the code repository and added to the supported modules list in gitlab(external link).

How does the lead agency operate the pool?

The following diagram provides an overview of the development pool lifecycle. The lifecycle takes place over a 3 month period, to align with the release schedule. It takes a month and starts at the beginning of each release month - that is in February, May, August and November. Each step in the diagram is described below.  

Step 1 - Preparing the backlog

The product manager copies all new items logged in the CWP workspace into the pool backlog. Where the information is unclear, the product manager contacts the person who logged the item. The description needs to explain what the enhancement is and how it benefits agencies. The items are assigned a unique ID. The items are assigned a category, so that they can be logically grouped.

Step 2 – Adding estimates to each item

The SilverStripe CWP team reviews new items and adds a rough estimate, to indicate the scale of the work required. Where it is hard to provide an estimate they will add assumptions as comments. If an item is large and needs to be scoped first, they will only provide an estimate for the scoping work. The backlog with estimates is dated and loaded in the CWP workspace library: ‘Backlog records’.

Step 3 – Consulting with the agencies to prioritise the backlog

The product manager sends the backlog to each agency relationship manager. The relationship manager consults with staff working on their websites as to which items are a priority. The agency picks a number of items in proportion to their usage as follows:

Contributing to the pool = 3 picks

For each small stack = 1 additional pick

For each medium stack = 2 additional picks

For each large stack = 3 additional picks

E.g. an agency with 1 small stack and 1 medium stack would have 3 + 1 + 2 = 6 picks.

An agency can apply multiple picks to one item. Each agency’s picks are sent to the product manager, who records and collates the information. The prioritised backlog is loaded in the CWP workspace library: ‘Backlog records’. 

Step 4 – Planning the next release

The product manager plans the release with the SilverStripe team based on the outcome of the prioritisation exercise. The planning identifies which items are planned for the next 3 month period. The planning will take into account:

1. The priority placed on the item by the participating agencies.
2. The actual and forecast pool hours available.
3. Work that is being undertaken already outside of the co-funded development pool.
4. Any dependencies between the items and other work underway.
5. An approach where 75% of the time is used to address large items (over 100 hours estimated) and 25% to address small items. (This aims to deliver quick wins and keep the backlog manageable).

The product manager creates the pool development plan for the next 3 month period. The plan includes the names of other agencies who have picked the item. Items that are not included in the plan are prioritised again in the next quarterly cycle.

Step 5 – Senior responsible officer approves plan

The pool development plan is reviewed by the lead agency and approved by the Senior Responsible Officer. The plan includes the output of the prioritisation and explains how the items have been selected for the 3 month period.

Step 6 – Load approved plan into the CWP workspace

The product manager loads the pool development plan into the CWP workspace folder: ‘Pool development plans’.

How does SilverStripe iteratively develop items in the plan?

The general approach taken is:

1. SilverStripe manages the development.
2. SilverStripe is responsible for quality assurance.
3. The lead agency product manager acts as product owner, attending the sprint planning and demos.
4. The product owner makes contact with the agencies to define acceptance criteria as required.
5. The product owner invites agency staff to attend the demos as required.

SilverStripe follows an agile methodology to deliver the items:

1. The items are logged into JIRA for tracking, and converted into agile stories.
2. For each story acceptance criteria are agreed.
3. The team reviews the stories and sizes them before each sprint.
4. A group of stories is selected for each sprint based on their priority, size and any interdependencies.
5. The product owner is available for clarification during the sprint.
6. The product owner attends a demo at the end of the sprint to decide whether the stories can be accepted. Stories that are rejected go into the next sprint.

From time to time, the development team may identify that an item is significantly larger or more complex than planned. In this case they will raise it with the product owner who will decide whether to continue or return the item to the backlog with a revised estimate and explanation.

Please note, statements on this page do not apply to the Mini stack which does not have co-fund hours or picks.