Tag Archives: Agile

Who is the new Agile leader?

Into the Unknown - Thomas Hawk - Flickr Commons

Into the Unknown, Thomas Hawk, Flikr Commons

My previous blog put a case for why we need a new style of Agile leadership. To enable self-managing teams to contribute and thrive within the complex ecosystem that is the organisation of today, Agile leaders need to understand their role as fourfold:

  1. As a coach; to share knowledge, skills and perspectives to development people
  2. As business driver; to maximise product lifecycle profits
  3. As purveyor of purpose; to connect people with the purpose of what they do
  4. As an enabler; to support  people to thrive within their environment

Even for traditional managers, there’s probably nothing controversial about these four roles, inspired loosely by the thinking of Michael Hamman and Michael Spayd. In fact to varying degrees, traditional managers might even feel that they fulfil these four roles now.

Traditional managers may perceive themselves as coach, in that they expect individuals to develop a learning plan, and if time and budget permit, they support an employee achieving it.

Nigel Dalton, CIO of REA Group, described in an ITNews interview online as, the Godfather of Agile in Australia, describes the role of Agile leader as coach:

“The company is divided into a set of teams focused on a kind of consumer ecosystem where each one is discreet from the others. Commercial property owners is mine; which is the smallest one. [The others are residential property owners and property developers]. We have understood that [there] is a kind of …‘unique customer experience’ in each one of these ecosystems.

[We asked] what if we put a full multidisciplinary team on those, and we chose a collective group to manage it?

Thus, I am not the general manager of commercial real estate – there isn’t one. I am the steward or coach of a group of seven people who are IT, sales, marketing, product, legal, finance, and human resources. Young managers in their thirties, who’ve got every competency to work as a team, and run that 40 million dollar business. I am there as their coach and all the Agile techniques come in under that. It is pretty self-contained and self-directed. It has its purpose and goal that flow down from the main company purpose. We have replicated that across the company – this is the primary structure.”

In traditional management the focus will largely be on the business role. The narrative on this would be “I reward individuals and teams who do whatever it takes to get over the line”.

The purpose role is a tricky one. Barely a middle to large sized enterprise today exists without some sort of mission statement. In traditional management, the existence of this mission statement and some resultant values might be perceived as bringing purpose to people working in an organisation. I can tell you from experience though, that the yearly exercise of requesting folks shoehorn their performance into the predetermined values of the company doesn’t yield much sense of purpose.

And finally to the enablement role. Traditional managers no doubt perceive themselves as enablers. They want their teams to succeed and would do pretty much everything to ensure this happens. I question though whether traditional managers would always take a holistic approach to enabling, seeing their team’s role in success of the whole organisation, rather than just success of the individual team.

Lisa Frazier, in her talk on Agile leadership at Agile Australia 2016, described how an Agile leader enables, by adopting a “follower-centred leadership style”. She cites three behaviours associated with this:

  1. Working for success of your team members above yourself
  2. Actively listening to your team
  3. Being a good follower

My favourite quote ever is from Nigel Dalton, at the same conference: “Leadership is not boss-ship, it’s servant leadership. Don’t ever mistake not being at the front with not being the leader”.

Jeff Smith, CIO of IBM, in the keynote address at Agile Australia 2016, said that “people come to work because they are ambitious and share the mission. The leaders’ job is to remove the obstacles”. Throughout this series of blogs, I’ll explore how great Agile leaders fulfil on their role as enabler.

Throughout this series of posts, I’ll contrast the role of Traditional Managers with Agile Leaders. What happens, when we ask great Agile leaders to reflect on these four roles in relation to the following leadership activities?

  • Decision making & problem solving
  • Communication
  • Delivery
  • Learning
  • Acknowledging success & rewarding right behaviour
  • Continuous improvement
  • Innovation

Read on to discover the questions great Agile leaders ask themselves in realtion to these activities.

 

Why Agile leaders need to ask themselves new questions

steampunk

We know that organisational culture can be shaped by the worst behaviours leaders are willing to tolerate, but can culture be shaped by the best behaviours that leaders are willing to amplify? This was a question I asked myself after hearing Dipesh Pala, IBM Agile Capability Leader for Asia Pacific, speak at Agile Australia 2016.

Last year’s VersionOne State of Agile Survey identified that four of the five top impediments for Agile adoption relate to management. Over a third of respondents cited:

  • Lack of management support
  • Company philosophy or culture at odds with core Agile values
  • External pressure to follow traditional Waterfall processes
  • Lack of support for cultural transition

The first impediment, lack of management support, needs no further comment, but when you think about it, managers also have accountability for company philosophy, pressure to follow Waterfall processes and lack of support for cultural transition.

Let’s start at the beginning, and the beginning is the most dominant style of management today, commonly described as command and control, or traditional.

Command and control was considered effective because our understanding of organisations was that they work something like the picture in this blog post.

Jurgen Appelo, author of Management 3.0 would describe this as complicated. There are many moving parts in this machine. There is also cause and effect. If one part isn’t working, it affects another part of the machine.  It almost certainly takes some time to learn all there is to learn about this machine, but, ultimately it is knowable.

Command and control was considered a way for managers to keep the machine in working order. So complicated means not simple, but ultimately knowable.

Appelo, on the other hand, describes what we know to be true of organisations today – that rather than them being complicated, they are in fact complex.

What is the difference between complicated and complex? Well, picture a rainforest and you can imagine complex.

A good friend of mine’s parents had a holiday house smack bang in the middle of a forest east of Melbourne. I found it a restful place – the river, the bird life and the amazing towering trees. This couple found it less so. So relentless was their weekend activity of cleaning bird poop off the veranda and sweeping the forest floor free of leaves, that they eventually sold the property.

A forest is a complex system. Complex systems exhibit:

  • Feedback loops – part of an output is used for new input
  • Spontaneous order
  • Hierarchical organisation
  • Emergent organisation
  • Numerosity – or an indefinite quantity of individuals

Other examples of complex systems are ecosystems, the universe, Earth’s global climate, the human brain, the stock market, a living cell and even organisations. Appelo describes complex as not simple and never fully knowable, given that too many variables interact.

The current thinking on organisations is that they are in fact complex adaptive systems. A complex adaptive system is a dynamic network of interactions. It is a system in which individual and collective behaviour mutates and self-organises, corresponding to a change-initiating event or collection of events.

Steve Denning also regards organisations as complex systems, but he remarks that it is the shift from semi-skilled to knowledge work, that means we need to re-examine the “unspoken assumptions…of the inevitability of … the practices of traditional management” such as command and control.

The management expert Peter Drucker notes that “Workers throughout history could be ‘supervised’. They could be told what to do, how to do it, how fast to do it and so on. Knowledge workers cannot, in effect, be supervised”

Perhaps the relentless bird poop cleaners and forest floor sweepers were a bit like command and control managers trying in vain to control an ever changing complex adaptive system.

How then can leaders of today enable self-organising teams to contribute and thrive within such an ecosystem? This introduction is the first of an eight part blog that tackles leadership for an Agile organisation.

Read on to understand the new four-fold role of Agile Leaders.

Agile Maturity Checks – Use with Caution!

Agile maturity check

Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.

At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.

My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.

It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.

Take a look at it and use with caution!

  Not yet On the way Mature
Standups We don’t run standups. We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins.
Team rhythm As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro.
Process Our way of working is painful. Process gets in the way of us getting stuff done. We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. Our way of working fits us perfectly. We have just enough process to get stuff done easily.
Speed We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. We get through stories, but there are frequently blockers, or process glitches. We get stuff done really quickly. No waiting, no delays.
Requirements Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria.
Analysis Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria
Sizing We aren’t yet sizing our work before bringing it into a sprint. Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. We have a regular rhythm of story sizing and involve the entire team in this process.
Velocity We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. We sometimes finish stories (including testing) in the sprint. As a team we always finish all the stories (including testing) we commit to in a sprint.
Sprint planning We aren’t yet conducting regular sprint planning. Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it.
Agile wall We don’t yet have an Agile story wall. We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do.
Showcasing We aren’t yet showcasing. We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built.
Retrospectives & Learning We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases.
User experience support
We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds.
User experience integration
We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy.
Testing Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD).
Build Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products.
Releasing Releases are extremely difficult. Our preference is to release at the end of the project. Releasing is tricky, so we aggregate as much work as possible before releasing. We have a regular rhythm for releasing. It is fast and painless
Collaboration & Communication We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response.
Empowerment – ways of working It’s the job of leadership to suggest how we can work better. It’s sometimes difficult to get traction on improved ways of working, but we give it a go. We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work.
Empowerment – product We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. Our regular cycle it to respond to learnings from customers. It shapes our backlog.
Contribution We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product.
Fun &
Celebrating
Success
Boooooooring. We do not celebrate successes. There are some smiles about, but celebrating success isn’t something we really do as a team. We have great fun working together. We find ways to celebrate our success.

How we can work smarter

question markDeakin University’s CIO William Confalonieri’s paper The CIO Reborn. Emerging from a profound identity crisis to seize the future sets a number of challenges for enterprises, including the following:

  • How do we pioneer new customer engagement strategies?
  • What delivery models best fit the challenge of digital disruption?
  • How can workforce enablement make us more able to adapt to this new, still forming digital environment?
  • How do we build a culture of sustainable enterprise change?
  • How can we assist the business to reinvent itself from the front-end?

I would add to that list, how can we offset the financial risk associated with predicting our digital future?

ADOPTION OF AN AGILE LEAN MODEL

An Agile Lean model sees enterprises utilising the following principles:

  • That business value based prioritisation will get rigorous consideration into planning
  • That self-managing cross functional teams are the engine room of adaptive delivery
  • That embedding a build-measure-learn cycle allows more attentive response to customers
  • That a mindset of continuous improvement will drive enterprise change
  • That incremental delivery will offset the financial risks of big bang delivery

HOW THIS MODEL SUPPORTS TACKLING CHALLENGES HEAD ON

New delivery models = better engagement with business

The key strength of Agile methodologies is intensive business engagement. In traditional projects the business provides requirements and then exits until the project is delivered. Using an Agile approach, the business works hand in glove with technology teams. The business is available on a daily basis to plan, answer questions and approve the incremental delivery of work.

Incremental delivery = offsetting financial risk

The risk of the big bang approach to technology delivery is twofold:

  1. Digital disruption may have changed the landscape by the time the project delivers
  2. Return on investment is not realised until the end of the project

Agile incremental delivery offsets these two risks by:

  1. Providing early delivery of features to fit an ever changing market
  2. Immediate return on investment through deploying the most highly prioritised features first

Improved customer engagement strategies = success

The following Lean Startup principles closely engage customers to enable enterprises to succeed:

  • Validated learning through testing our assumptions about our customers
  • More innovative accounting to set the right milestones and measure progress
  • Implementing a build-measure-learn cycle to understand how customers respond, and then learn whether to pivot or persevere. This accelerates the customer feedback loop.

Workforce enablement = greater engagement

Agile teams are self-managing and more productive than non-Agile teams. Teams are comprised of the following roles:

  • Product Owner – who defines what is going to be built and is the conduit to the business, primarily responsible for prioritising delivery of assets based on their business value
  • Scrum Master – the servant leader, who removes obstacles on behalf of the team, monitors in-build activity and manages the flow of reporting information
  • Developers – the engine room of the team who are empowered to suggest improvements to product features or team processes

Agile is a pull model, where teams commit to sustainable delivery of work, rather than a push model, where a Project Manager delegates work. This model of workforce enablement leads to greater engagement, idea generation and ability to respond to a still forming digital environment.

Building a culture of sustainable change = continuous improvement

Building a culture of sustainable enterprise change is a mindset change for many organisations. Organisations can foster change by:

  • Supporting teams in adopting the Agile practice of reflecting on how to become more effective, then tuning and adjusting accordingly
  • Creating opportunities for individuals and teams to learn about Agile best practice through brown bags and guest speakers whose ideas may rock our own
  • Encouraging continuous improvement, and investing in the technology and expertise to support it

Supporting business reinvention = creating new job roles

Enterprises need the right level of support to introduce the Agile Lean practices that will see them tackling challenges. Agile Lean Methodologies cover many concepts and principles and are not something simply learnt by attending a course. Key to supporting business reinvention is creation of job roles that fill the following gaps:

  • Provision of Agile coaching, to support practitioners in the delivery rhythm, until they become self-organising to deliver independently
  • Support for the Senior Leadership team on coming up to speed with Agile practices
  • Identification of gaps and opportunities for improvement in Agile practices
  • Development of an Agile framework that will fit both operational and project delivery teams
  • Examination of what program management means in an Agile context
  • Investigation and implementation of a model for scaled Agile delivery
  • Adoption of a successful model to encourage practitioners to share ideas through communities of practice within win outside of the organisation
  • Support to develop a greater emphasis on building the ability to measure into everything we build

 

How Lean can a pizza be?

lean-pizza_croppedThe other week a diverse group of Agile, Scrum and Lean practitioners from the Geelong area got together at the Waterfront Kitchen to figure out just how lean a pizza can be!

Lean startup is a method for developing businesses and products first proposed in 2011 by Eric Ries.  Based on his experience working in several US startups, Ries claims that businesses can shorten their product development cycles by adopting a combination of business hypothesis driven experimentation, iterative product releases, and what he calls validated learning.  The concept has wildly taken hold outside of the startup arena, as it promotes enterprises reducing market risks by iteratively building products or services to meet the needs of early customers, thereby sidestepping the need for huge initial project funding and expensive product or system launches and failures.

Lean startup aligns really closely with Agile, which harnesses an iterative, rather than extended development cycle to better fit product, system or process development to what users need or want.

Geelong Lean Coffee, the community of practice I founded some months ago to get Agile practitioners in Geelong meeting to share ideas, organised the event.  We teamed up with another newly formed community of practice, Geelong Entrepreneurs, to bring together likeminded professionals invested in using Agile, Scrum and Lean startup to succeed.  The evening was sponsored by Deakin University as a means to contribute to building economic, social and human capital and facilitate conversations about Agile in the Geelong and Deakin community.

The guest speaker for the evening was Simon Cuce, the Software Development Manager from Xero Accounting Software. Simon told the great story of how Xero have grown from a startup in 2006, to a globally successful enterprise using Agile, Lean and common sense. Topics covered included how best to manage the product backlog, good conduct at the daily standup, how Xero uses a variant of the Spotify “tribes” model, and much more.

What really impressed us was Simon’s description of the enabling culture at Xero.  It’s an environment where staff are empowered to do a great job and where innovative ideas easily bubble to the top.  At Xero, business value is equated with customer value and coupled with the Agile framework, teams can quickly pivot to get great features to market.

The benefit of events such as this, is that Agile practitioners can learn from others in the community and contribute their knowledge to building a Digital Geelong.  Some of the conversations on the night saw Geelong professionals collaborating with the guest speaker about spinoff ideas that utilise APIs to develop new products collaboratively with Xero.

We are enormously grateful for the university’s support of this event.  Being able to have access to the wonderful Waterfront Kitchen after hours provided a central venue for all to attend, and if you measure value based on the calorific content of the incredible salami pizzas served on the night, then all who attended could attest to the enormous value of the evening.

Applying Lean Startup thinking to product development

railway_station_500x377This morning on my way into work, I was traveling from a different train station. Totally unfamiliar with the station layout, I was for a moment, confused about which end of the platform to stand on. I would be exiting the train at Southern Cross station, and I wanted to be at the Collins St end of the platform when I exited. Another passenger must have registered my puzzled expression and asked me if he could help. I explained that I needed to commit to waiting for the train at one end of the platform, or at the other end, and that I would either be very wrong, or right. At that moment the thought struck me that this was a good analogy for Lean Startup thinking in product development. If I was right, then I’d have only a short walk to catch my next train. But if I was wrong, then I’d know just as soon as I arrived, and I could correct my path.

In his 2011 book, The Lean Startup, Eris Reis proposes that key to the success of new product ideas is testing your assumptions. Rather than launching with a fully-fledged product, on which you have expended huge amounts of effort and money, he advocates for pushing to market at least some features, to test your assumptions about what would be useful or attractive to customers. This allows you to fail early and inexpensively, or succeed early too!

There are a few approaches to this. One is what he calls “smoke and mirrors”, which is more an approximation of a product than the real thing. It provides some functionality for customers, but this is not necessarily driven by the end state processes or software. Instead it simply approximates the end state, so that you can test if the end state is going to meet customers’ expectations, ahead of investing in building the end state.

The advantage of taking this approach is pretty clear. You can validate your assumptions before investing the resources to build the end state. In the university, this type of model could apply if we were building a new online form to replace an existing process. Our product vision might be an end to end process that collects the information required from students and manages cross faculty exchange of information. Taking a Lean Startup approach, perhaps we could build an interface that collects the information, simply to validate that it will be compelling for students, but retains some manual manipulation of data, just until we validate we are collecting the right data and have created a form that is compelling enough for students to engage with. Obviously the “smoke and mirrors” manual part of the process can be replaced with a digital solution once we have validated our assumptions, and perhaps pivoted to find the optimal way to collect the initial information required.

Another way that Reis suggests arriving at an optimal product is through releasing something that may not entirely constitute a minimum viable product. He argues for putting aside our deeply held beliefs that we can only launch an end state high quality product. Where a product provides new and exciting functionality for users, assumptions about if it will be useful and compelling for users, also need to be tested. By launching with just one feature, instead of a planned 10 features, users can still interact with the product and provide feedback and requests for additional features that can be built in response to this.

In my work environment, this might look like us responding to some website feedback about a certain feature that users would like to see on the website. We might develop the beginnings of this feature and then advise the users who requested it to have a go at interacting with it. By engaging in a dialog with users around the beginnings of the feature, we are most likely to be able to shape it in such a way that it best fits users’ needs.

Resisting the urge to hold back until a fully featured version is available can be a huge mindset change. Essentially though, this type of scenario is typically played out with early adopters, who are the intelligence behind driving future features and pushing the boundaries of the Internet of Things. These users tend to be heaps more tolerant of early prototypes and appreciate engagement on development of product features.

My first scenario in this post was about being right, or very wrong. Obviously the stakes aren’t very high, when all I’m doing is choosing between which end of the train platform to stand on. The idea in Eric Reis’ Lean Startup model, accords with this though. Test your assumptions early and always, when the stakes aren’t high. Users will appreciate it, and so will those holding the purse strings to your product!

The “What’s next?” of Agile – Business value part 2

what-next-300x188Having covered some basic concepts of business value based prioritisation in my previous blog post, this one is for those who want to take the next leap into backlog grooming.

Prioritising initiatives based on business value makes sense, because it helps you see return on investment. But what happens when you have a whole bunch of initiatives that all contribute to something that is highly valued, such as improving user experience.

My team was recently in this situation. Scattered throughout our backlog were a whole bunch of stories that loosely fell under the umbrella of optimisation activities. Many of them didn’t have sponsors in the business, so there was no one to plead their case. Some of them couldn’t demonstrate a huge improvement in user experience, but would deliver efficiencies for our internal workflow, and hence help free up our time to deliver other initiatives with high business value. Some resolved what we call “technical debt”, which refers to the eventual consequences of poor system design, software architecture or software development within a codebase.

So, it was clear that these stories had business value, but how would we decide “What’s next?”.

I decided to go back to a classic Agile technique that sees you measure the business value of a story against the ease or difficulty in actualising it. My approach is always to involve the team, so I ran a workshop where we gave these stories their own time in the sun. We looked at each of the stories and rated their business value on a scale of 1 (low business value) to 3 (high business value). Then we rated the stories on 1 (easy to deliver) to 3 (hard to deliver). For each story we were able to derive a priority rating by dividing business value by ease of delivery. For example, we decided that creating reusable form assets had a business value of 3, and an easy of delivery of 3, so its priority score was 1 (3/3=1). Another story had a business value of 3 and an ease of delivery of 1, so its priority score was a 3. (3/1=3). This allowed this story to be prioritised above the reusable form assets.

When we ordered the stories we’d been grooming by their priority rating, the prioritisation felt pretty right!

This technique was useful for us, both because it made us really consider the stories and their business value, but also because it helped us truly prioritise pieces of work in our backlog. What we also learnt was the power of putting our heads together to make the assessment around “What’s next?”.