<- previous post in this series on refinement
In theory, the planning ritual could be automated. Look at everyone’s calendar for the upcoming sprint, estimate velocity and grab the things from the backlog that will fit. In the middle of a well-known project, it may be that simple and only take minutes. If you are beginning a project or at the end, the team may find planning more difficult. During those stages, there may be confusion over which items take priority.
To keep the team and the code healthy, every team should have an advocate for the work that is least likely to make it into a sprint. Regardless of your project stage, there are three areas that will likely get little attention:
- retro action items
- discovery/future work
- technical debt
In this post, we explore these areas as three roles that you can play to make an impact on your team’s effectiveness.
The retro ambassador
If you are in the planning meeting, your team probably just did their retrospective on the previous sprint. The team came up with some great ideas for how to be the most awesome team ever. Inevitably, these ideas will be forgotten just in time for the planning meeting. The retro ambassador delicately weaves the ideas from retro into the planning of the next sprint. They bring the checklist of ideas from retro and action items and see how they fit in the current work. Did the idea of pair programming come up in retro? Suggest that two members of the team work on one of the larger items this sprint and report back on the effectiveness.
The retro ambassador should be the person who pushes the team to plan for change rather than just talk about it in retro. One important thing to remember is that not every retro idea is a good idea. The retro ambassador should suggest experiments and the team can decide in the next retro whether the experiments were successful enough to implement in the long term.
The explorer
Whether you are at the beginning, middle or end of a project, there will be unknowns. Some teams naturally want to prioritize discovery while others dangerously kick that can down the road. The explorer strives to make the unknowns known by pushing to bring the discovery work into the current sprint.
Unknowns come in various forms like:
- Blockers/dependencies on other areas of the business (product, sales, marketing…)
- Vendor choices, investigation, and API integration
- Architecture decisions and approvals
It is important to note that the explorer should not be the person doing the work of discovery. That is the work of the team or even another stakeholder outside of the delivery team. The work of the explorer is to encourage the team to not feel comfortable until decisions are made in the areas of the unknown.
The debt collector
All projects lead to some form of technical debt. Just like the financial world, debt can be pushed off and ignored until it cannot be ignored anymore. The debt collector is someone who understands the team’s current technical debt and develops a prioritized backlog. These refined stories are brought into sprints in a cadence that reduces the backlog of debt rather than let it continue to grow.
Many teams find it hard to tackle technical debt because it does not have the appeal of a new feature. Yet, a code review with chunks of deleted code feels liberating and refreshing. Removing the complexity of supporting legacy and current code makes future work that much simpler. The debt collector is the advocate of these feelings and truths.
Back to work
While planning feels simple, the known feature work dominates the sprint. To counteract this tendency, you can influence your team by taking on roles that advocate for the work that is equally important but least likely to be prioritized.
For greatest impact, look at the last few sprints your team has completed and find out which role your team lacks. Work with your manager/lead and begin to present yourself in planning as either the retro ambassador, the explorer or the debt collector.
Your team will thank you for it.
Are there other areas that are unrepresented?
