Suite Project Agile Guidelines¶
All teams working on the Suite Project must follow these guidelines. This document is to be kept up to date with new definitions / meetings and what reality dictates as soon as possible. It should be the source of truth of the Agile Project of all Teams working inside the Suite.
The goal of the Suite is to build an ecosystem of services that interact between each other in order to fulfil its common goals and the required use cases that the business imposes.
In order to achieve such goal, we have different Development Teams that will focus on a specific area of the system. However, these systems need to eventually interact with each other in order to execute our use cases, so we need a way to make sure that we are all working towards that common goal in synchronicity.
The Suite Planning Team¶
The Suite Planning Team, commonly known as The Planning Team, is in charge of defining the scope of the Suite and its entire ecosystem. The Team, as a single unit, is the Product Owner of the Suite.
The Planning Team works in advance defining the road-map of what they need in order to satisfy the business' requirements. They do that by having a Backlog where they write Epics and narrow them down into Features.
This Backlog, is "The Backlog". It is the source of truth of everything that needs to be done in order to move forward with the project. The Backlog is defined by the Planning Team on a high level, and implementation or feature specific details are defined in conjunction between the Planning Team and Development Teams.
The Planning Team also prioritizes the Backlog according to what they need first and they can have a high level view of all Dev Teams and identify dependencies between their work.
The Planning Team has regular meetings with Upper Management in order to gather requirements. They review the Suite's Backlog and review the items that will be worked on, and identify possible new Features to be included.
Development Teams¶
Development Teams are composed of a Product Owner, a Scrum Master and Developers.
During a Sprint, Dev Teams work on the Features which were assigned to the Dev Team by the Planning Team, depending on their area of expertise. Development Teams must fulfil these Features in the given time, or work with the Planning Team to figure out a more accurate timeline based on their expertise and estimation of the effort required to perform the Feature.
They also must have at least a single scheduled recurrent Refinement Meeting during each week of the Sprint in order to start working on the Features that the Planning Team has assigned to them for the upcoming sprint. The Dev Team is in charge of refining the Features into User Stories and Tasks, and providing an estimation for each of them.
The Planning Team will also be available during that time for meetings with each Team in order to help refining the Features.
The Dev Teams won't define new Epics or Features. It is the Planning Team's responsibility to do that. That does not mean they can speak up and request certain Features to be added to the Backlog or be prioritized.
Dev Teams will only create User Stories for the Features that the Planning Team adds to their Backlogs. If Refactors or Architectural changes are required, which do not add immediate value to the business, then the Dev and Planning Teams have to work together to prioritize it. They will decide in which sprint it will be included.
The Team's Capacity and Day's off are configured by each Dev Team. The Planning Team only set's the Sprint's Date.
Dev Teams that are also working on LTS versions of our applications, will have to organize work in order to fulfil what they need. We recommend that LTS and Suite Sprints are both kept in sync, since this has other values (like for personnel rotation), than the Suite's Iteration.
We also recommend Dev Teams split their sprint into Suite and LTS. In order to do that, we recommend to add days off in the Capacity to have a better representation of the available manpower.
Suite Iterations¶
In order to measure progress for the Suite as a whole, and to be able to better plan Dev Teams inter-dependencies, we have the concept of a "Suite Iteration".
A Suite Iteration lasts a calendar month, and it is divided into a Planning Week and a three-week Sprint.
All Dev Teams will share the same Sprint Dates. This means that we will all do Planning and Sprint on the same dates.
Sprints will be created by the Planning Team, and they will also configure its start/end date.
In the context of a Suite Iteration, we will have scheduled a bi-weekly meeting to perform Scrum of Scrum (SoS). SoS is a standup where a spokesman from each Team let's the rest know the current status of the Team and specially if they have any blockers that need to be resolved in order to complete the Features that were required from them. The Planning Team will lead the meeting, which should include each Team's Product Owner, and optionally the Scrum Master and other Team members that the Product Owner considers they need to attend. This may be necessary in cases where we work on Features across-teams which need a fine-grained catch up.
The Sprint¶
During Sprint Time (it's easier to start backwards, bear with me), the Planning Team focuses on defining the Epics and Features for the next Sprint, as we mentioned earlier. Dev Teams focus on developing the User Stories and Tasks for the current Sprint, and have regular refinements by their own, and some with the Planning Team in order to define the User Stories and Tasks for the Next Sprint.
New Features may be added by the Planning Team to the Next Sprint's Backlog up until the last day of the Current Sprint. (Planning Team will, hopefully, not do that right?).
The last day of the Sprint is not included into the Dev Teams Capacity, since it is reserved for the Suite Demo and Retrospectives. (Easier to do this than add Work Items representing this happening.)
On the last day of the Sprint, we will perform a Demo showcasing the Features that were developed during this Suite Iteration. The Planning Team leads the meeting and a spokesperson from each Dev Team showcases what they did. This Demo is about Features that adds value to the business. We won't talk about Refactors or other Architectural changes.
After the Demo, each team will have a closed-doors meeting to do Retrospective. Then, we will have a shared Retrospective meeting of 15-30 minutes where a spokesperson of each Team will share the output of the Team's Retrospective. Purpose here is not to share internal day-to-day team stuff, it should be focused on other kind of stuff like process inconveniences, or too many workload, etc.
We can then have a beer and close the Suite Iteration!
But fun beings again next Monday, where we start the Planning Week!
The Planning Week¶
When we reach the Planning Week, the Next Sprint's Backlog is already closed by the Planning Team and no new Features can be added. Each Dev Team focuses an in-depth refinings of technical tasks as possible. Dev Teams will schedule meetings with the Framework Team and Planning Team in order to nitpick implementation details and business doubts about the Feature.
This is the time where Research may also be conducted on new technologies or new ways to do things. Proof of Concepts of next sprint's features may also be developed during this time. Perfect time for Pair Programming! perhaps with a member of another Team!
The Planning Team's single responsibility during the Planning Week is to help the Dev Teams refine. So make sure you use their time for that.
Scrum Master's Responsibility during the Suite Iteration¶
As we already the know, the Scrum Master is a very important role of an Agile Team. Naturally, the Scrum Master plays a role in the Suite Iteration. She/he makes sure that the team's focus is on the iteration goals.
Let's break down the Scrum Master's role for each week of the Suite Iteration:
Planning Week¶
At least one meeting must be booked during this week by the Scrum Master with the Planning Team and the rest of the team. The objective of the meeting is to make sense of the features the Planning Team has added for this the upcoming Sprint.
The Scrum Master must also notify the Planning Team when the backlog for the next sprint has been completely refined into tasks and estimations are finished.
If at any time there's signs of not enough work for the available capacity, the Scrum Master must notify the Planning Team so that new features are added to the upcoming Sprint.
Sprint Week #1¶
The Scrum Master keeps her/his regular responsibilities during the Sprint. However, he must make sure that at least one Weekly Refinement meeting is done by the team. We recommend scheduling a weekly 1hr meeting for refinements.
During that meeting, the team will start to brainstorm on how to implement the initial Features that the Planning Team is assigning to the upcoming Sprint.
User Stories may be written at this stage breaking down the feature into use cases.
Sprint Weeks #3 and #4¶
The Scrum Master keeps her/his regular responsibilities during the Sprint.
During these two weeks, User Stories must be written with enough details to get them estimated by the team during the planning session.
As we get closer to the Planning Week, there shouldn't be any doubts on how to implement the features. Doubts must be cleared in backlog refinement sessions time before the planning week starts
During any time of the Suite Iteration, meetings may be booked with the Planning Team for gathering more requirements of the Features. Meetings may also be booked with the Suite Framework Team for brainstorming on technical implementation details. When in doubt, do reach out.