Usage of roadmapping techniques

The support of proposition P4 ‘Using release-planning or roadmapping techniques decreases the short- and long-term planning gap’ was found in every case. Every reviewed case was found to use roadmaps and had small short- and long-term planning gap. ‘Case 1 – Bank’

was found to use yearly, quarterly, high-level, and refined quarterly roadmaps. The high-level

roadmap is presented to management during the quarterly session: ‘it's mainly just the name of the Epic [and] how much time … in months [it takes to implement] or whether it's going to be finished within this quarter or we run into the next quarter’. The detailed roadmap is more refined and includes the one- to two-week duration of every roadmap item: ‘I then create a detailed roadmap and then within this detailed roadmap, there are chunks of the work that we have to do; it's a week or two usually’. There is often a dedicated roadmap manager who aligns the roadmaps of all the teams: ‘the roadmap manager has that view for all the POs, all the squad’. As shared by the product owner, the ‘Case 1 – Bank’ does not use release planning. In the ‘Case 1 – Bank’, software is released once major parts are ready: ‘I have releases at the end of an Epic or maybe once in three months’. The Product Owners of the ‘Case 1 – Bank’

discussed working to align Sprint plans with the roadmap to prevent any possible gaps. Support of proposition P4 is, therefore, seen in Case 1.

The interviewees from ‘Case 2 – Media’ reported using roadmaps with a one-year time-horizon. The ‘Case 2 – Media’ company’s roadmapping approach is quite elaborate: requests are gathered from different departments and put into templates. Every request must explain what problem it solves, and data that can justify the size of the problem must be provided. At a joint session of Product Owners and technical architects, prioritization is determined using SAFe’s WSJF technique (Scaled Agile Framework, n.d.-c). The workers indicate time criticality, value, and technology, and the teams provide the high-level effort to build the initiative. After looking into the capacity of the teams, the top ten requests are added to the roadmap. This process results in an intermediate roadmap that is presented to the stakeholders.

The necessity and value of every request must be proven by a business case. The reason for double-checking requests was elaborated upon by I05: ‘it is because the WSJF is really based on feeling and how we use Fibonacci [numbers for high-level estimations] there, and then business cases going to confirm or disprove our choices’. The roadmap is then once again

matched with the company strategy: ‘We see that if what we have chosen matches the company strategy … we sit down with the product team, we validate it, and then we agree: ‘this is the roadmap for the next year’. The short- and long-term planning perspectives are matched via requirement prioritization (which is described in 6.1.2): ‘I think we work pretty closely with the road map, so our road map, what we work on is our road map’ (I05).

‘Case 3 – Food Retail’ uses three month and one-year roadmaps. In comparison with

‘Case 2 – Media’, Case 3’s roadmap creation process is not very elaborate: ‘We have a roadmap, which kind of drafts out what are the features we want to deliver per quarter … but usually that's just a one-liner of what we want to want to do and when’ (Product Owner – Interviewee 11). Despite their simplicity, Case 3’s roadmaps are used by the organization as the inputs for the prioritization process and for aligning Sprint planning with the company’s larger goals (See section 6.1.2 for more details). Release planning is almost completely unused by the ‘Case 3 – Food Retail’ company. According to one interviewee, instead of using release planning, ‘We want to get more and more to continuous development’. In other words, the company wants release software when feature is finished and integrated into overall solution.

Since the ‘Case 3 – Food Retail’ company uses roadmaps for its long-term planning, prioritization processes, and for bridging PI planning with Sprint planning, Case 3 supports proposition P4.

‘Case 4 – Retail’ uses one-year roadmaps that are aligned with the financial year. Case 4’s roadmaps for the upcoming two quarters are more detailed than those for quarters that are farther off, and they consist of t-shirt sized features mapped into Sprints. Some teams have their releases mapped into the roadmaps as major milestones. Since the ‘Case 4 – Retail’

company has adopted SAFe, the company’s detailed planning process involves using a PI plan.

One of the interviewed Product Managers (I13) completely removed the time dimension from the roadmap they were following: ‘we say what we want to work on now, what we want to work

on next and what we will work on later. I think it's very, very compatible with a must-do, could-do and should-could-do’. I13 further elaborated on the Company’s planning strategies with the following statement: ‘So me putting out this timeline doesn't make sense because there are so many unknowns. So, we only take the time factor into account when all but the majority of the unknowns are addressed, and that's pretty much what you see in the planning, and that's three months’. In other words, release planning is almost unused by the ‘Case 4 - Retail’ company.

The company uses its roadmaps as inputs for more detailed planning, and PI planning and backlog prioritization are the mechanisms the company uses to align short- and long-term planning perspectives (roadmap). ‘Case 4 – Retail’, therefore, supports proposition P4.