...

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

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.

...

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 <role of the one benefitting>

...

When <user action>

Then <system response>

And remember:

4. Sprinting or Continuous Flow

4.1 In 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
• Starting the sprint
• 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 the sprint

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 Work for 2 weeks to complete 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. 

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

4.2 In Kanban

Kanban has no limits on time, but on amount of work in process. By focussing 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.

If there is no limit on the amount of work in progress, or if those limitations are not honoured, 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.

5. Inspect & adapt

Releases – manage your versions

...