Versions Compared

Old Version 6

changes.mady.by.user AJ van Spanje [AgileVisor]

Saved on

compared with

New Version Current

changes.mady.by.user AJ van Spanje [AgileVisor]

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Table of Contents

1. Introduction

outlinetrue

Introduction

Agile is a framework for a way of working in which: 

  • experts are empowered, to take ownership and create high-quality solutions,
  • the gap between IT and Business is bridged, through input and validation by a business-representing Product Owner,
  • transparency, alignment and early escalation (asking for help) are key,
  • short cycles lead to adapting and improving plans,
  • and we experiment with process improvements to gain efficiency.


Jira JIRA can bring a new level of transparency to an Agile team, opening up the backlog and work in process beyond the team’s location.

The platform can be used for Scrum or Kanban, but ultimately it’s just a tool: it’s only as good as the data we put in.

If we want to use JIRAJira, we should:

  • populate it with clearly written stories,
  • maintain it daily,sharing our progress and refinement.

for then JIRA Jira can provide easy searching and automated reporting.

...

Jira setup - Portfolio management

The Project in JIRA Jira is much larger than an Information Systems ‘project’ – it is the full backlog for a product that your a team (and maybe others) manages.

YME management has decided that we have three Information Systems release trains – Consumer Processes, Business Processes, and Enablement. 

Initially, we there will have be one single JIRA Jira Project for this entire portfolio, which will allow us to easily assign stories between the development teams easily.


Each Outside Servicedesk, each team will have their own team board (either Scrum or Kanban), with their chosen team name in the title.
Thanks to the "Yamaha Team" field, which contains an entry for each team, only stories assigned to owned by this team are visible on their own board.

...

Value & measurement - why & how?

When wishing to change the status quo, it is vital to do two things:

1) Clearly state your goal: why does it have value to do what you propose?

2) Clearly define how you will measure whether that goal has been reached.

In Agile, this is the responsibility of the Product Owner, though others (like Business Analyst) can support.

Image Added

It is done by writing a "User Story" that clarifies the why and "Acceptance Criteria" that clarifies the how.


Your Scrum Master can help you summarise your needs as suchcoach you to write brief summaries:

User Story

As a <position <role of benefitter>the one benefitting>

I want to be able to <software function>feature>

So that <business goal>


Acceptance Criteria

...

When <user action>

Then <system response>


And remember:

Image Modified

Image Removed


A quick note regarding estimation:

  • We estimate value in the Jira field "business value"
  • We estimate complexity to develop in the Jira field "story points"

These estimations use a simplified Fibonacci range (0, 1, 2, 3, 5, 8, 13, 20, 40, 100).

The reason for this is that people are much better at estimating small numbers.

There is no real difference between a "48" and "49", because any estimate that large will include a large portion of uncertaintly. 

For this reason work with large estimates is broken down into smaller, workable pieces (that we can still test to validate a piece), and re-estimated.

A recommended tool/game for estimating together with a group is: https://planningpokeronline.com/

...

Sprinting or Continuous Flow

4.1 In Scrum

Scrum

We work in increments of two weeks, because it's easier to plan realistically when timelines are short:

  • The scrum master creates a sprint in Jira with the correct dates
  • The product owner (PO) sets a sprint goal that will deliver value to the business
  • The full team together chooses or creates
  • Creating a sprint
  • Setting a sprint goal
  • Choosing stories to fulfil that goal
  • It is checked that the "Definition of Ready" (do we know all we need to know, do we have necessary translations, etcetera) is met
  • The scrum master starts Starting the sprint

Work for At YME sprints lasts 2 weeks. Within that period of time we strive to complete the chosen work. 

At the end of this period, after the developers have built and unit tested, a QA officer has done integration and regression testing, and the PO has validated the results, the team together reviews which this selection of work. Then review the work meets the acceptance criteria , and plan when to release the results.

Any work not completed moves back to the backlog, and could be selected as part of a new sprint goal in next sprint planning.

4.2 In Kanban

 

Before starting a new sprint, we hold a retrospective - looking back at how people and processes behaved during the sprint, and how we can become more efficient and more happy together.

Image Added

Kanban

Kanban has no limits on time, but on amount of work in process. By focusing our efforts on a single task, we strive to move items to Done in short cycles.

  • Choose a limited selection of work (one item per persondeveloper)
  • Do not take up new work until the old work is completed
  • If an item gets blocked, the entire team works together to resolve the block before continuing work

Work We work to provide continuous flow: processing work items through the required workflow (development, peer review, testing, uat, release) as soon and smoothly as possible.

5. Inspect & adapt

Releases – manage your versions

.

If there is no limit on the amount of work in progress, or if those limitations are not honored, it is not Kanban but a simple to-do list.

It's not easy to work though blocks sometimes, but remember that if you explain to a requester why something is not possible and they change or cancel their request, that resolves the block as well.

Releases or 'fix version/s'

Either way of working needs to at certain points deploy software, in a production release.

In Jira, this is administered by assigning a 'Fix Version/s', which bundles together everything that goes live on a specific date. Release managers use the fix/version to understand what needs to be prepared for deployment together.

Two things are important in this:

  1. We should use the naming convention when creating a new fix version/s.
  2. We should release a fix version/s in Jira after the deployment is successful.

The first helps everyone understand which system the release is for, and which period it took place in; while the second clears deployed items from the 'done' column of Kanban boards.

Inspect & adapt

Using the tool Jira consistently, means that we obtain transparency of our process and progress. This allows our team to Inspect how we are doing, and Adapt in order to gain higher efficiency, and grow together.


Each team board contains standard reports. 

  • these are

...

  • only as good as the data we put in

–for Scrum

–for Kanban

–Dashboards

Searching – across or within projects & teams

–Basic or Advanced

–Export to file

–Bulk change

6. Recommended learning

  • for Scrum the Burndown Chart and Sprint Report are useful
  • for Kanban the Cumulative Flow Diagram is useful

for higher level planning the Epic and Version report are useful, but we will need to grow into these reports yet at YME.


A Burndown Chart shows the progress during a sprint. The more the red line follows the grey line, the better:

Image Added

A Sprint Report shows the results after a sprint. The fewer items have a * or are removed from sprint, the better:

Image Added

A Cumulative Flow Diagram shows how WIP is limited and progress is made in Kanban. The slimmer the colored line between backlog/resolved, the better:

Image Added

Recommended learning