Semester planning — prioritisation and scheduling in ASOS Tech
Setting the priority, aligning your delivery capability, and providing transparency to all levels of the organisation is simply the right thing to do. How do you go about putting some of these things in place in a fast-paced organisation? Read on to get a little bit of insight into how ASOS is learning how to do this more effectively.
In August last year, we made the decision that it was time to put in a better process for prioritising, planning, and scheduling the work for each quarter across our Tech teams.
Why did we do this and what problems were we trying to solve?
- Changing priorities that meant teams had to context switch, disrupting teams flow
- Siloed backlogs and roadmaps causing dependency management challenges
- Not having a joined up, visible view of what Tech was working in each quarter
- Unable to articulate to the business what we are currently not working on
Now, planning events of this type are certainly not new to a lot of organisations (think Program Increment (PI) planning type activity), but they were new to ASOS Tech as we had historically used more of a “rolling wave” approach with frequent updates to priorities and plans.
You may have also noticed that we talk about planning for a quarter, yet we call it Semester planning. We did this intentionally as we were not sure if running this quarterly was the right cadence for us, we may over time find it better to move to being twice or three times a year and so getting stuck with the wrong name for something is never a good thing.
Version 0.1 alpha — our first Semester planning event
As we had never done Semester planning before, we realised early on that it was not going to be perfect. And to be honest, that is fine with us. We did not want to spend a lot of time getting the perfect process in place, or copying a process from a scaled framework or such that does not actually solve the problems in our context.
Instead, we decided to take an agile and iterative approach with an experimental mindset allowing us to test and learn from it. We also made sure people were aware of that from the start when we introduced the concept, both for the inputs/outputs and how we planned for, and ran it.
Getting ready for the event
We formed a small working group (as less is more when doing this kind of thing) and defined a purpose for Semester planning a.k.a. the “why.”
“To provide a joined-up view on what we are delivering/working on in Q1 (Quarter 1) and what we are not”
We set out several goals:
- Ease the path for planning
- Decide the priorities for the quarter
- Create a roadmap that we could publish to the business and wider tech organisation
This led to the first important question; what would success look like?
Firstly, we wanted to help areas understand capacity; to get to a point where they had a good idea of their capacity to work on features, balanced with BAU activity and hygiene/technical debt. This was important to ensure we do not overload teams and there is slack in the schedule to handle unplanned work.
Secondly, we want to enable the creation of rolled up feature roadmaps. Each area had their own roadmaps and delivery plans, so we wanted to help create an overall view for each feature and how that impacted each area and the proposed schedule for the interdependencies.
Finally, we wanted to understand how the discovery process for new work was disrupting teams. We were aware there are a lot of asks on the team to look at potential new work items, and we believed this was having a negative effect on a team’s ability to get into flow.
The next question was; how do we plan this event?
We had to decide who to involve, what we needed people to do before the event, how the event was going to be run, what tools we would use to support the process and whether we did this as an in-person, hybrid, or remote session.
Involvement wise, we kept the numbers down to make the process manageable. We thought this was right for the first planning session as most of the work in the teams’ backlogs had already been defined using our previous process, so there would be few new items of work being asked to fit into the quarter. We included our Delivery Leads, Senior Product Managers and Senior Architects, with the understanding that they would be able to reach out to their teams as needed during planning with the aim to include more people once we better understood what worked (and what did not).
Before the event, we realised we needed a common process for gathering the work the delivery teams were doing across the quarter. We knew each area had their own plans and roadmaps but these were not in a consistent format.
We therefore focused on visibility and created a Miro board with a Semester Plan template and asked the Delivery Leads to complete the information. The template included the core concept of the feature, dependent and impacted areas along with links to assets such as the architecture triage and business case. There was also a section covering capacity, planned features, hygiene, unplanned work, and planned discovery items.
We used Miro to capture this information in one place, though we realised early on that this was not a sustainable approach due to the manual overhead in doing this. That being said, Miro was the catalyst that helped us formalise our planning process, putting our team on the path to achieving improved visibility and efficiency.
In line with the theme, you are hopefully grasping by now, we treated this as an opportunity to learn what we would need to move towards in the future.
The planning event itself
As we were moving towards a world post-Covid, we decided we would also use this event as an opportunity to bring people together physically in the same space. We used a large room in ASOS with plenty of whiteboard space, tables, and a few Microsoft Surface devices to enable the session.
We decided to run the event over 3 days:
Day 1 — We reviewed new work candidates (both feature and discovery work), in priority order and looked to see if there was any capacity available in the teams to bring in their work — or see if some of the work took a higher priority than what was currently planned
Regroup day — We left time between Day 1 and Day 2 to allow the delivery teams to have any follow up conversations based on changes arisen as part of Day 1. This allowed time to iron out risks, gather any additional information and validate what was possible.
Day 2 — We regathered as a group, to review any changes and agree on the final priority of the work for the quarter. We also allowed time to share updated roadmaps and talk though any significant risks.
What we learnt from V0.1
Surprisingly, we found that simply getting people together in a room to discuss a list of upcoming deliverables and priorities was incredibly beneficial. It led to a productive session, with lots of healthy conversation. We gathered a bit of feedback at the end of the session on the Miro board in real time and you could see that people were curious in how we could improve the process.
During the event, we discovered that we were attempting to accomplish too many tasks simultaneously, such as comprehending, disseminating, prioritising, and clarifying dependencies. Additionally, we lacked clarity on the objective of the sessions. Were they intended for discussing spare capacity, prioritisation, road mapping, or something else entirely? This necessitated a change.
Finally, we had asked people to create and share roadmaps in Miro — however, this was not a sustainable solution as:
- it took a lot of work for everyone to create
- it would require a lot of work to maintain
- they are disconnected from the actual work in a delivery team’s roadmap
- ADO bi-directional sync in Miro was released 3 days before our initial dry run so we did not have time to implement it into the planning itself
- no ability to pull this out into our reporting needs
While Miro was not the right tool for us to use for roadmapping, it was especially beneficial for gathering feedback on how to iterate on our processes going forward. The working group held a retrospective to reflect on the process and we decided to focus on these things for the next iteration:
- Simplify the management of the portfolio
- Published upfront plans and guidance on the purpose for each session
- Enable a consistent way to create delivery plans in Azure DevOps
- Move away from people filling in the additional Delivery Portfolio spreadsheets
Version 1.0 — Time to go again
We looked back at the purpose for Semester planning and decided to update this to be more outcome focused:
“Alignment on priorities across teams, and transparency about what we are working on”
Tooling and process improvements
We started to choose a different path around the tooling we wanted to use; however, we did not want to change how we have empowered teams in their own ways of working.
Our goal was to streamline delivery reporting, increase visibility of cross-team dependencies, and align with ASOS’s strategic initiatives. To achieve this, we concentrated on utilizing the tools that teams use every day in a more efficient manner across the wider Tech portfolio process. This allowed people to focus on valuable work instead of wasting time updating spreadsheets and presentations.
We established a “Tech Portfolio” backlog in Azure DevOps, which contained all the Epics for ongoing work and potential new work items for the current quarter.
We requested that every area set up a Feature Kanban board with well-defined Features, which included a title, description, and start/target date estimates.
Once each area had added their Features, we asked them to link these back to the Epics in the Tech Portfolio.
This was the first step in creating a single, cohesive cross-technology backlog. With this new system, we were able to create delivery plans across each area, filter by parent portfolio item at a strategic level, while also highlighting dependencies between teams.
This new system was also beneficial in allowing for automated delivery reporting, as it became the up-to-date source of truth. Overall, we started to see that our efforts would allow for greater efficiency and transparency in the delivery process.
A new plan for the event
From the last event, we learnt that we needed to provide a little more guidance and a longer runway for people to align to, both for publication of the business-aligned priorities and to allow people to understand each work item and its dependencies before the actual semester planning event.
We introduced a new plan and ran a kick-off event with specific asks for a slightly wider audience, which included things such as:
- Ensuring any proposals for work in the quarter is submitted to the portfolio
- Supporting the triage process for new work items
- Getting delivery plans created in Azure DevOps
- Making space in diaries to attend all breakout sessions
- Inviting additional people from your area to cover items being discussed
- Setting aside time before the event to review the priorities and new work items for the quarter
We found that providing just a little more guidance and forward planning helped. However, a little guidance then leads to more questions — from the list above as example, people where asking “who are the additional relevant people to invite?” and “how do you want us review the work items?”
All good questions. We realised we did not have all the answers, so we used this feedback to help us provide our teams once again the information and guidance they needed.
We realised that we needed people out in the field helping our delivery teams prepare effectively for Semester planning. We have a great team of Agile Coaches in ASOS, and they spent time with each area helping them setup their local backlogs and delivery plans, and answer any questions they had about how best to link up to the Tech Portfolio. There were also lots of frequent questions coming from each area so the Coaches were able to both advise and feedback to the working group to improve the process.
We left the planning event itself in the same format as before and just focused on the planning, process, and communications as we wanted to see how this helped the process. It is not always good to change everything at the same time.
What did we achieve?
- 34 top priority work items triaged and discussed
- 135+ people involved to help plan and schedule the work
- 10 domains with centralised delivery plans in Azure DevOps
What we learnt from V1.0
Rather than just focusing on the mechanisms of planning and running the event, we started to notice the efficiencies and impact of introducing this new process across ASOS Tech.
Semester planning was starting to minimise substantial change coming into the teams during the quarter, allowing the teams to better focus on the priorities in hand.
Dependencies were being identified up front and work was better planned across affected delivery teams providing improved alignment.
We had taken a good step forward towards using Azure DevOps as our source of truth for the work our engineers focus on, providing improved delivery tracking, delivery plans direct from the tool and hence starting to eliminate assets that duplicated information and the manual work required to do so.
Finally, we realised you could not expect everyone to have the same level of competency in a tool so we kickstarted a training program around Azure DevOps.
Version 2.0 — Our latest iteration
Onto the latest round which has just finished at the time of writing this.
Better comms and preparation
For the latest round, there has been subtle shift in the language we used when getting ready for the Semester planning period.
People were more used to the event and its rhythm, so we focused on the clarity of the message for what we needed people to do with an eye on helping them not just participate in the process, but own it.
Comms have been more specific, for example:
- Submit your work for the quarter by X date so it can be considered for prioritisation
- Priorities will be shared for Semester planning by X date
- Roadmaps in Azure DevOps should be up to date by X date
- Alignment sessions for features should be setup by Delivery Leads during X period
We were able to be clear on the expectation for each session we organised, for example the weeks before the event was about triage, understanding and aligning on new work items. Day 1 and Day 2 session were about scheduling work, highlighting dependencies, and finalising priority.
During the recent Semester planning event, we noticed a real engagement in the process from all areas of technology; both inputting into the portfolio, participation in the event, working together to finalise the priorities.
Most importantly, we saw people taking accountability and ownership of the sessions that needed to happen. Our Delivery Leads were doing this work already, the shift is that there is a light framework and rhythm that is now in place to help make this process more effective on a regular cadence.
What did we achieve this time round?
- 144 top priority work items triaged and investigated by the team
- 150+ people involved to help plan and schedule the work, with reps from every area
- 38 of the most complex items deliberated during the event
- 97 work items scheduled for the quarter
What have we learnt so far? A final reflection
Establishing Semester Planning as the new way that the Technology department understands, scheduled, and talks about delivering work has been a significant shift.
It has generated positive feedback from the delivery teams and the business, which we believe has significantly reduced the amount of context switching and distractions that we observed previously, along with allowing us to clearly align with the strategic objectives in ASOS.
We have driven far better visibility of our portfolio of work, streamlined the reporting process by aligning work in Azure DevOps enabling us to extract information rather than force the use of additional PowerPoint and Excel delivery sheets.
We are not where we want to be just yet, that is ASOS and our desire to continually strive to be better. The process is in a good place and will continue to evolve and improve.
About me
I’m Paul — the Head of Agile here at ASOS and I look after a small and superb crew of Agile Coaches.
I love coaching people and teams and spend my time looking at how we can continuously improve to deliver more effectively and efficiently.
Outside of work, I’m a family man and there is nothing I enjoy more than spending time outdoors with my wonderful wife and and my fabulous kids.
