Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

In HDX, the development process is Agile and the audit trail for the work done is held in JIRA in the form of issues, which are the fundamental units of work/planning information in JIRA. Where issues are part of a larger piece of work they are grouped under an epic.

JIRA Issues

The start of the development process is the entry of issues into JIRA. Issues can be one of three different types:

  • Story: Stories are issues associated with an epic. That is, stories are for work that accomplish your main goals for a cycle.
  • Bug: A bug is an emergent (unplanned) issue that fixes a fault in the software that exists on master. Bug issues are not associated with an epic.
  • Improvement: An improvement is essentially a feature request. Like a bug, an improvement is emergent. Unlike a bug, an improvement adds new functionality. Improvements differ from stories in that they have no epic link.

Certain metadata should be completed to create an issue:

  • a Summary of what the issue is about
  • the Component that the issue concerns eg. CKAN
  • a detailed Description that makes it clear what is required
  • the Priority of the issue - Highest, High or Low. Lowest will not get done (smile)
  • any Linked Issues which is helpful for example for seeing what might block this issue
  • the Epic Link of the larger piece of work this issue is a part of if applicable

The issues, once created, go into the list of outstanding issues (Product Backlog) which can be seen here.

Scrum

The Agile process HDX uses is broadly similar to Scrum, a framework to support teams in complex product development. In Scrum, the time available to work is broken down into time periods known as Sprints of two weeks during which a “Done”, useable, and potentially releasable product Increment is created. It is helpful to look at a diagram of the Scrum Framework.

Roles (Scrum Team)

Product Owner (Yumi)

The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. She is the sole person responsible for managing the Product Backlog which includes:

  • Clearly expressing Product Backlog items.
  • Ordering the items in the Product Backlog to best achieve goals and missions.
  • Optimising the value of the work the Development Team performs.
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

She may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. 

For the Product Owner to succeed, the entire organization must respect his or her decisions. Her decisions are visible in the content and ordering of the Product Backlog.

No one can force the Development Team to work from a different set of requirements!

Scrum Master (Dan) 

The Scrum Master is a servant-leader for the Scrum Team. He helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t and encourages changing these interactions to maximize the value created by the Scrum Team. He helps the Development Team to create high-value products and removes impediments to their progress.

He serves the Product Owner in several ways, including:

  • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.
  • Finding techniques for effective Product Backlog management.
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items.
  • Understanding product planning in an empirical environment.
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

Development Team (Arti, Alex, Serban)

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. Only members of the Development Team create the Increment. They are self-organizing: no one (not even the Scrum Master or Product Owner) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.

Process

Sprint Planning (Monday XX:XX CET for X hours)

The work to be performed in the Sprint is planned at the Sprint Planning by the entire Scrum Team:

  • The inputs are the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team (intuitively since we don't measure velocity).
  • The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve this Sprint Goal.
  • The Development Team selects items from the Product Backlog according to what they can accomplish over the upcoming Sprint and plans the delivery of those items, producing a Sprint Backlog.
  • The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.
  • By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organising team to accomplish the Sprint Goal and create the anticipated Increment.

Daily Scrum

The Daily Scrum is a 15 minute event for the Development Team to discuss:

  • The previous day's work.
  • Progress toward the Sprint Goal.
  • Work for the next 24 hours.
  • Any impediments to progress.

Deployment to Staging and Testing (+2 weeks)

The completed product Increment is deployed to a staging server and testing is performed. Relevant team members from outside the Scrum Team can help with testing.

Sprint Review (+2 weeks, Tuesday XX:XX CET for X hours)

A Sprint Review is an informal meeting, not a status meeting, held at the end of the Sprint and attended by the Scrum Team and key stakeholders invited by the Product Owner:

  • The Product Owner explains what Product Backlog items have been "Done" and what are not "Done".
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
  • The Development Team demonstrates the work that it has "Done" and answers questions about the Increment.
  • The Product Owner discusses the Product Backlog as it stands. She projects likely target and delivery dates based on progress to date (if needed).
  • The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
  • The Product Backlog may also be adjusted to meet new opportunities.

Minor Bug Fixes and Deployment to Production ( > Sprint Review date)

Any last minute minor bug fixes are implemented and if there are no serious issues, the completed product Increment is deployed to production.

Sprint Retrospective (+2 weeks, Tuesday XX:XX CET for X hours)

The Sprint Retrospective is a formal opportunity for the Scrum Team to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools.
  • Identify and order the major items that went well and potential improvements. 
  • Plan ways to increase product quality by improving work processes or adapting the definition of "Done" if appropriate and not in conflict with product or organizational standards.
  • Enumerate improvements to its development process and practices to make it more effective and enjoyable for the next Sprint.

Periodic Demo to HDX

When major pieces of work are completed eg. an Epic, there is a demonstration to the wider HDX Team which offers an opportunity for discussion and feedback.


  • No labels