Our Ways of Working
The Azure Landing Zone team has the following regular ceremonies:
Stand Up
The Team get together to share developments, surface blockers, and move work forward. It’s about empowering the team and building accountability.
It’s a meeting that’s in direct service of moving towards completion quickly, without hiccups.
Everyone who participates in the stand-up should understand this and get value out of the time spent together.
- Attendees - All team.
- Stand-up time: Max length 20mins
- Frequency - 10am Daily/morning. share Jira board
Three Questions for Stand-up meeting:
What you did yesterday?
- “Yesterday, I focused on Jira ticket number HC-33 relating to HMPPS data migration”
What will you do today?
- "Today, I am continuing to work on Jira ticket number HC-33, with a view to complete today.”
Any Blockers?
- "I could use another set of eyes on the deployment into Development as it keeps failing.”
Remember the stand-up should be quick and concise and move to the next team member.
Backlog Refinement
Product owner and the rest of the team review items on the backlog ensuring storys contain the appropriate items (DOR), that they are prioritised, and that the items at the top of the backlog are ready to be worked on. This activity occurs every week.
Activities that occur during this refinement of the backlog include:
- Weekly Refinement ran by Delivery manager/Product manager – Every Thursday 2pm - 60mins
- Review items in Backlog with the status ‘Needs Refining’ with the team and ensure all items included using Definition Of Ready checklist within the user story example user story , remove not required stories, create new stories if required, estimate, design clear, i.e. meet Definition of Ready, assess priority, prioritise.
- Backlog is prioritised list of all work (most important item at the top) including stories, tech debt/defect/etc. and ensure ticket meets DOR
- If the Backlog reaches a maximum of top 10 items that the status is ‘Ready For Development’ then we hold off from Team refinement for at least 2 weeks. This is to give the team chance to start work on those items.
(Product Owner and Delivery manager meet every Tuesday 11am - This is used for preparation for the team Refinement session on Thursdays).
Backlog Status Definitions
New - A Brand new ticket that is missing to much information to be refined by the team.
Needs Refining - A ticket that is ready for the team to refine and add dependencies, effort, Description, Contact, Acceptance Criteria etc.
Stuck - A ticket that has been assessed but can’t progress for reasons.
Ready For Development - A ticket that has been refined and agreed by the team as read.
Board Lane\Status Definitions
To Do - The ticket is ready to be worked on and should be picked up by the next person available.
In Progress - The ticket is being actively worked on by one or more members of the team.
Blocked - Progress cannot be made on the ticket after work has started.
Done - All acceptance Criteria are met and the ticket is completed.
Too Difficult - Something that is actually impossible/outside our skill set.
Swerved - Issue has been removed and work will not be completed for reasons that should be added as a comment before swerving it e.g. Duplicate or don’t want to/no point in it.
Definition Of Ready (DOR)
Serves a precondition for an item from Backlog before entering ‘ToDO’ (ready for development) to prevent problems before it starts. As we use a prioritised backlog the items on top should meet DOR. A definition of ready deals with the user story, wherein the user story is ready to be taken into ‘ToDo’. It doesn’t need to be “100 % defined” covering all the acceptance criteria. However, it should be “ready enough” only when the team is confident that they can successfully deliver the user story. It will help in saving ample time if each user story meets the definition of ready before it’s Ready for development. The Team can use Definition of Ready as a guide when preparing for user stories for upcoming work. For the ALZ team, it is used as a checklist to make sure that there is an increased chance of success in delivering the completed user story, and that there are enough thoughts involved in building the user story before they start to deliver it. So finally, Definition of Ready brings back the focus to backlog refinement meetings and lookahead planning activities.
Definition of Ready helps in minimizing the Rework on a user story.
Definition of Ready Checklist - Please note we can add to the list below
| Definition of Ready |
|---|
| 1. Description & Contect |
| 2. Acceptance Criteria |
| 3. Title |
| 4. Developer Notes |
| 5. Understand Timeline |
| 6. Estimation of effort |
| 7. Who to contact about work |
| 8. What Outcome is expected |
| 9. Dependancies |
Definition Of Done (DOR)
The Definition of Done is an agreed-upon set of items that must be completed before a user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.”
Ensures that transparency and quality of the completed work fit the purpose of the product and the overall goal
The ALZ team owns the Definition of Done, and it is shared between the engineering Team and the Product Owner. Only the Engineering Team are in a position to define it, because it asserts the quality of the work that they must perform. Please note we can add to the list below it is not fixed and will grow over time.
Definition of Done Checklist - Please note we can add to the list below
| Definition of Ready |
|---|
| 1. Acceptance Criteria Met |
| 2. Released Environments |
| 3. User Sign-off |
| 4. Acceptance tested |
| 5. Documentation |
Retrospective
A retrospective is an opportunity for the team to learn and improve. It is time set aside – outside of day-to-day routine – to reflect on past events and behaviours.
Every retrospective should at a minimum result in a list of “Keep Doing – positive stuff” and “things that could use improvement.” Those lists may not be particularly long and exhaustive, but each has a few standouts in each column.
Beyond calling these items out, the discussion should uncover why these things occurred. The goal is to understand how to replicate the positives in future work by creating new best practices (or reinforcing existing ones) while identifying the root causes for the negatives so they can be prevented or mitigated going forward.
- Monthly retro with ALZ Team - 60 mins
- Tools we use to host retrospective Miro – ALZ Team Retrospectives
- Team given 10 minutes to add comments via post-it notes to each of the columns (see column descriptions) ALZ Team Retrospectives then we discuss. Actions are created and assigned.
| More of | Less of | Stop | Keep Doing | Start |
|---|---|---|---|---|
| What we are doing today is really helping us , but we would benefit from doing it more often | What are we doing today, that brings value, but we spend too much time on? it would be beneficial if we keep doing it, but perhaps a bit less (frequently) | What is slowing us down, not adding any value, or too time consuming | What are we doing today that is helping us, and we should focus on keeping doing it. This is usually something very positive that might be forgotten if we don’t bring it to our attention. | What should we start doing or incorporate into our way of working to improve as a team? This can be an experiment, something that a colleague did on another team, something we read about … |
After each retrospective, notes should be typed up displaying what was discussed in each column and any actions. Use ALZ RetroTemplate for creating Retrospective notes
Theses should be shared with the team and saved within the Azure Landing Zone teams area.
Create a folder in Teams under Azure Landing Zone teams area to reference the retro date and save your document in the folder. For example: ALZ_retro_21.9.22.docx