6. Research results (presentation and interpretation)

6.1. Cross Case analysis

6.1.2. Goals alignment

Every case involved in the study was found to use an elaborate process for aligning long-term goals with those of the Sprint plan. A variety of techniques are used, including Product Backlog management, roadmaps, and OKR (Objectives and Key Results). The data reveals that goal alignment is primarily done by Product Owners. The Product Owners

frequently use a ‘breakdown’ process that breaks high-level goals, typically called ‘Epics’

(product backlog items, roadmap items) into smaller tasks or work-items called ‘Features,’ and

‘Stories.’ Epic, Feature, and Story, though their relationships vary from case to case, follow a hierarchy of priorities and are arrived at via an analytical process driven by either the Business Analyst or Product Owner. The tasks associated with each Sprint are prioritized in accordance with the priorities of the Stories and Epics, which, in turn, are clearly aligned to the Product Backlog and roadmap priorities. This prioritization process was described by I05:

‘For each roadmap item, I create an Epic. Onto this Epic, I have features and after and the features that have user stories. So I start working on the Epics, which are on the top of this prioritized roadmap. I prepare user stories, and … they just end up at the top of the backlog, and we start working on them, so it's always from the top and next from the top, the next’.

The ‘breakdown’ process was described by the Product Owner from ‘Case 1 – Bank’

in a similar manner: ‘So we use Epics and then the POs generally break down the epic on refinements with the team. So, we can have, maybe, a couple of very high-level features, three or four features, and I think breaking down the epic into features’. I13, when discussing ‘Case 4 – Retail’, said the following: ‘We handle one milestone in the planning, and that milestone will be broken up into Epics. …and, later on, we'll break down an epic into user stories or maybe into spikes if we don't know the entire scope of a particular story’.

The cases demonstrated additional priority and goal alignment mechanisms, including alignment with management, advanced backlog management practices, and frequent meetings.

I03 stated: ‘And actually before Sprint planning, we have Sprint alignment with the management … in which I discuss what I have planned for the next Sprint’. ‘Case 3 – Food Retails’ adopted a ‘data-driven backlog’ mechanism that helps Product Owners align long-term planning at the strategy level with priorities on the level of two Sprints. This was described as

the following process: first, product owners create one-page documents that capture basic data associated with questions such as: ‘What is the platform?’ ‘What is kind of the general solution?’ ‘What is the business case of it?’ ‘What are the success metrics?’. Second, both the business value of the initiative in question and the effort required to build the initiative are estimated in relative sizes, or ‘T-Shirt’ sizes. Each relative size of business value has direct mapping onto sales, as described by I11: ‘So we say everything that adds more than 2.5 million additional sales … score five; everything below 100k is one’. At the fourth step, the business values are divided by their ‘technical size’, and an ordered list is put into an Excel spreadsheet known as the ‘data-driven backlog’. This technique is similar to the ‘Weighted Shortest Job First’ (WSJF) method popularized by SAFe (Scaled Agile Framework, n.d.-c). With the WSJF approach, I11 stated, that Product Owners apply their own judgements to change the calculated priority: ‘And then, of course, we don't only look at the kind of objective score, but there are also sometimes reasons why you would like to prioritize something higher because it's a really important and large strategic initiative or it's an important enabler’. The data-driven backlog is reviewed every four weeks and is the basis of the Sprint planning for Agile teams. I11 highlights cyclic nature of the process: ‘that's kind of a cycle that we do every four weeks … we have a freshly prioritized list at the feature level that feeds into the teams so that they know what they need to work on for the upcoming four weeks’. This approach appears to reduce goal misalignment to nearly zero for ‘Case 3 – Food Retails’.

The approach used by ‘Case 1 – Bank’ involves aligning Epics on the roadmap with Sprint goals. The roadmaps are quarterly and consist of Epics. The priorities of Epics are discussed and committed during special events called ‘Quarterly Business Reviews’ (QBR).

Product Owner creates Stories for each Epics accordingly to the Epics priority for the full quarter. During Sprint planning, Product Owners make sure, that what was planned is based on the roadmap. A ‘Case 2 – Media’ I05 reported using a multi-step model similar to that used by

‘Case 3 – Food Retail’ that involves adapting elements from SAFe: ‘We make a split [of initiatives] based on teams … and then we start working on them based on priority. One of the things that we use from SAFe is the prioritization technique, WSJF’.

There were no indications in the data that goals and/or priorities misalignments relating to short- and long-term planning had occurred in any of the cases. The only mention of anything close to misalignment came in the form of the conflicting priorities of long-term goals (Initiatives or Epics) and non-aligned priorities between Sprint teams. For example, I09 stated the following: ‘While we needed [important] functionality to improve … the whole … project, that team was also working on a new application that was needed for… [legislative]

requirement. …two high profile things … so you escalate it … and we had a clear priority’).

All cases used elaborate process of aligning goals and priorities between short- and long-term planning and had small gap between short- and long-term planning. The data gathered by this study give strong support proposition P1: ‘Alignment of Sprint and Product Backlog goals decreases the short- and long-term planning gap’.

In document Agile Software Development Projects Long-term Planning in the Scaled Bridging the Gap Between the Short- and (Page 35-38)

Related documents