Arif is in charge of warehouse operations and has an idea which would help forecast demand with greater accuracy, reduce money tied up in excessive stock holdings and increase relevant geographical stock availability. He gets in touch with Pete and arranges a meeting to discuss his ideas, Pete is the Product Owner for team Bullet, A scrum team who are responsible for developing and maintaining the company’s Warehouse Management system. The company has several Scrum teams each aligned to distinct product areas and each product area has it’s own Product Owner.

Pete’s scrum team Bullet already has a long backlog of items but Arif is able to convince Pete that the potential savings from this initiative could be many millions year on year and is worth reprioritising high on the backlog... Pete owns the backlog and regularly reprioritises what he believes represents the highest value work, a large part of his job is ‘stakeholder engagement’ keeping them informed on progress and at times explaining why their feature has been deprioritised!

Pete is really excited by Arif’s proposal and can see the commercial advantages it should deliver, He invites Arif along to present his idea to the Scrum Team in one of their weekly backlog refinement sessions. Pete could have presented the idea himself but he likes the team to have close contact with the business and he’s found that pulling the business straight in with the development team eventually saves time and increases trust and understanding on both sides.

The team roughly estimate the size of work… It’s big and at this point Arif has no evidence that the initiative will return the results he hopes it will, There’s also lot of risk around the idea not just because of the size of the development effort but also technical architecture considerations which he has to balance against a potentially large ROI.

The team discuss the idea of doing a heavily cut down targeted prototype which will enable Arif to test his hypothesis but will be a much smaller piece of work. If successful they will commence on implementing their findings, If not the team will have only lost a timeboxed amount of time... Arif is disappointed at first but after some coaching from Pete he agrees to this approach.

The Scrum team works in 2 weekly iterations which they call sprints - During the current Sprint Arif, Pete and Sam (the team’s Scrum Master) work closely together and come up with a number of stories which describe several key aspects of functionality. At the next sprint planning session (Which they hold on the first day of every sprint) Arif and Pete present the stories... The team is very excited about the proposal and working on a technically interesting challenge however Sam is concerned that the team doesn’t understand either the stories nor the technology stack well enough to accept the stories into the sprint and instead she suggests a number of spikes are carried out to learn more and evaluate the different options, Pete also has a number of defects in the live system that he’s been getting grief over and collectively they agree that the team should look at the defects, work on a couple of spikes required to build the prototype and work on small reporting story that’s been requested.

After the sprint planning session the team holds a second session facilitated by Sam where they discuss the prototypes and experiments they want to conduct. This is more of a technical meeting where the team typically white boards ideas out and decide upon technical tasks to complete.... They also update their team scrum board with post-it notes indicating what defects and spikes they intend to work on and order the work in the agreed priority sequence.

The next day the team meets at 9:30 for their daily stand up around the large board. Pete usually tries to attend, He likes to understand progress and be available to answer any questions that might arise from the team. Two of the developers decide to work on the defects in the live system, Jane and Dave are keen to start looking at the spikes identified and decide to pair up together.

The team has been together for almost two years since the company transitioned through an ‘agile transformation’ they know the system well and are fairly confident they know how to fix the issues quickly.

The first thing they do is to write a number of automated tests, testing was all manual until recently but the team are increasingly relying on test automation backed up my manual testing to fill the gaps as required.

These automation tests both document how the system should work and reproduce the defects reported in the live system they then set about fixing the code. Once the automated tests pass they check the code into the code repository - At this point an automated build takes place followed by a suite of automated unit and behavioural tests… and about 30 minutes later a big screen on the wall goes green indicating that the work checked in has built succsessfuly and passed all tests! The developers call Pete over and talk through the defect fixes and demonstrate on the test system - Pete is happy with the fixes and as he deems it low risk they push the fix through into the production system straight away. Pushing code into production is now almost as simple as a single click.. It wasn’t always this easy!

Some years back this process was undertaken by multiple different teams. Completed tasks were uploaded to a test system for testing to take place by a separate test team... If successful they would be returned to the developers who would write a release pack and roll back plan and pass the change onto an operations team... The operations team would follow the release instructions and validate that the change was successful. Often releases would move back and forth several times between teams.... Releases were held up due to unclear instructions or code quality issues with the average time from development complete to the task being released being measured in many weeks.

The company had brought in an agile coach, Adrian to help during their agile transformation. Scrum teams had been formed by pulling people in from previous distinct disciplines and typically Scrum teams now consist of developers, testers and sometimes Business Analysts and system administrators. Once the scrum teams became more established Adrian had brought in a number of specialist technical coaches – These coaches worked with scrum teams introducing Test Driven Development and automated testing approaches... They also helped the different product teams build their own continuous integration pipe-lines and continuous deployment pipeline.

Meanwhile Dave and Jane who are also members of team Bullet are looking at the spikes identified in yesterdays planning session….. Spikes are a recent idea within the team suggested by Jane during one of the team’s retrospectives. The team now conduct spikes to help them understand large complex problems better or to test out multiple ideas before committing to one.

On each Thursday they have a backlog refinement session, this is an opportunity for Pete to talk about new features he’d like to introduce and for the team to ask questions. When they first started doing scrum Pete would turn up to backlog refinement with a pile of what he considered were complete stories – However during one of the teams retrospectives it was identified that this approach wasn’t working well. The team disliked being handed completed stories – They were often poorly understood and Pete grew tired writing all the stories up front only to be endlessly questioned about the details every week and forced to rewrite them before the team would accept them.

Adrian the companies coach suggested that instead Pete should come along with some high level stories and the team in conjunction with Pete should write them together...... This was rather painful at first however after a couple of months experimenting with the format it’s proved quite successful. The team have since started to add acceptance criteria to stories in BDD cucumber style syntax (Given – When – Then) This has helped to flush out misunderstandings early... And certainly helps to keep Pete busy working with the business to get the answers they require! Pete has also started to bring end users into refinement sessions from the business as required and it’s now quite common practice for developers to speak directly with the business when Pete isn’t available or where more specific subject matter experts are required.

For this session Pete invites Arif along and together they present the high level stories. Pete working with the team has identified a number of stories he would like doing first, these have been chosen around working on the riskiest assumptions Arif has and in proving or disproving some architectural concepts early.

One of the stories will involve some fairly major database changes and Jane is worried about the implementation…. Jane used to work as a SQL developer in a specialist SQL team but since the adoption of agile she now works full time in the scrum team – She still mainly does database work but has started to pair up with some of the C# developers and works very closely with the teams automation tester. Some of the queries are already taking too long and this could cause the system to perform unacceptably slowly during peak system times. The change is critical to the success of Arif’s improvement plan - But Pete is aware that if the derogation to service is too great they will have to abandon the prototype…. Sam suggests that this should be the first story worked on… If it’s found that it’s not technically possible they will only have lost a few weeks and can move onto other items in the backlog – Or to put it another way the team will have very quickly discovered that the prototype is not possible and they can switch to higher value work.... Previously the company would have spent much longer on large technical design documents before embarking on large projects such as this..... Often validation of architecture would only occur in the final stages of integration towards the end of a projects life and often led to long and expensive project overruns.

After discussing the spikes the team move on to some other stores that require clarification and does some story point estimation on the remaining stories. The team try and resist doing specific time based estimates instead performing relative estimates.

The following Tuesday is end of Sprint - The team meet in their break out area at 10am whilst Pete and Sam drag the teams scrum board in... Pete works through the defects and spikes that the team committed to do in sprint planning demonstrating them to various stakeholders who have attended the review The defects have already been released and he’s checked with the warehouse team that their happy with the fixes and relays feedback to the team.

Arif also comes along to see the spikes the team have been working on and to hear the feedback from what the team have learnt from doing the initial spikes and using this information they start discussing what is and isn’t possible.

The team breaks for coffee and meets up again for a team retrospective - This is lead by Sam whilst both Arif and Pete discuss what they want to achieve in the next sprint leaving the team to discuss how the previous two weeks have worked and identifying possible improvements.

The team uses the afternoon to tidy up some of their code base and make a few small changes that Pete requested during the Sprint review and they release the reporting story completed in sprint to the production system.

Wednesday morning they have Sprint planning again, Pete and Arif now have a good idea of what’s doable for the prototype and collectively with the team they decide what they should develop in the next sprint.

And the cycle repeats every two weeks... With Pete working very closely with the business understanding new requirements and helping to foster close relations between business teams and development teams.

Page Break

A year later the model is performing well however they are struggling to keep up with the number of demands on the team. Sam is concerned about the size of the backlog which has been steadily growing.. She’s been tracking the lead time between stories entering the backlog and being deployed and has noticed this time has been steadily growing... For a while she’s been persuading Pete to say no to new work more often and to both aggressively reprioritise the backlog and attempt to keep it’s size down to a minimum.... This has the advantage of ensuring that the team can pivot quickly and respond to change however Pete is aware that their product is loosing it’s competitive advantage the business are also starting to get frustrated that they can’t get all the features they require through the scrum team promptly.

As a remedy Pete wants to add more people to the Scrum team however Sam is concerned that the team is already large enough and adding people won’t necessarily increase the output... Instead she suggests that a 2nd team is spun up.

Sam will act as Scrum Master to both teams and Pete will be the Product owner for both teams running from a shared backlog.

Some ceremonies are now shared between the two Scrum teams. Planning consists of both teams, Pete turns up with a list of stories he’d like worked on in the next sprint and the teams pick which stories they’d like to work on. The teams then breaks apart for their individual technical planning sessions.

Backlog refinement is often performed separately but on occasions they decide to do it together where they think it would be beneficial or close integration between teams are required. Sprint reviews are held together and they do a mix of shared and individual team retrospectives.

This approach works well and within a few years there’s 4 scrum teams supporting the product - Each scrum team has between 4 and 7 team members and each team either has their own Scrum Master or one between two teams…. However Pete is still the only product owner for all teams.

Adrian who the organisation brought in originally still engages for a few days every quarter to do scrum health checks, coaching with the teams and executive leadership coaching. At one of these coaching sessions they discussed having a product owner and backlog per team.

Adrian wanted to explore with the business what they wanted to optimise the system around and explored models around various optimisations.

Page Break

Adrian asked what the affect would be on the following variables by increasing the number of product owners and backlogs :-

Ability to prioritise multiple backlogs to reflect most important value

Number of product backlog items each team understands well

Ability for the teams to change direction quickly – If the product was to pivot

Number of dependencies between teams

Number of items worked on in each sprint that are of the highest value

Number of items worked on in each sprint that were of low business value

Pete and Sam worked through the scenarios and reached the following conclusions.....

A product owner per backlog per team each reprioritising their individual backlogs would mean their was no longer one ordered backlog based on highest business value.

Teams optimising around their own backlogs would decrease the chance of teams understanding all items on the entire product backlog (the combined view of all backlogs)

Teams working on their own backlogs would decrease the likelihood that teams could work on any part of the system... It would increase specialist areas for teams

Specialist teams would increase the likelihood that teams would not be able to work on the highest value stories so the number of low values stories being worked on would increase.

As teams became more specialist there would be more dependencies between stories... More dependencies would increase queue length (waiting times) between teams and increase overall lead times

Whilst having a product owner per team would seem to be an optimisation – they concluded that it would merely optimise the efficiency of each team – However it would de-optimise the ability of the system to be constantly working on the highest value work at all times.

The current model ensures that Pete gets the stories delivered in sequence which unlocks the most value for the organisation.

However they also conclude that there would be a point where Pete would be unable to keep track of all stories and details, So if the teams were to continue to increase there would be a point where the PO’s responsibilities would need to be shared out and a degree of local optimization would be unavoidable.