SCRUM & Planning2 – HOW will we do this?

SCRUM Planning2: Architecting the unknown – The HOW.

In SCRUM Planning2 the focus is entirely on the team identifying the HOW of the WHAT being introduced by the product owner during the course of Planning1.

In Planning1 the product owner described WHAT the user stories actually contain and WHAT the result of the finished stories should look like. Now the team has the challenge to discuss HOW this user story should be implemented. Planning2 is really essential to the team to discuss, plan, architect, argue and agree on how the business user story should be implemented in software. Both, Planning1 and Planning2 are essential activities for the team to finally commit to what they plan to deliver within this sprint iteration.

In our company, we had user stories where individual software developers were sitting days and days to solve one huge technological question. Before entering Planning2 we still were at one user story worth around 40 story points. During Planning2 the whole team came together and discussed the findings of the individual software developers. And magically, they came to a solution – valued 8 story points – implemented during this one sprint and delivered as commited. The miracle of communication!

Planning2 – in essence – reserves real quality time for the team to think through the challenges of the user stories. Allow time to discuss, to argue, to joke, to de-focus, to be creative. A good result of Planning2 is a whiteboard full of tasks associated with the user stories.

SCRUM Planning Board

Ideally, the whiteboard contains a collection of tasks being identified during the discussions in Planning2. The sum of the tasks finally deliver the user story – the associated business value. In our Planning2 sessions we introduced a color coding scheme to reflect the kind of work to be done. Green – for example – stands for quality assurance testing tasks. The more experienced the team, the better the team members know each other – and trust them – the more trustworhty actually the result of Planning2.

When the team is finished with Planning2 they continue with the commitment. During commitment they discuss what user stories they are able and willing to commit. The commitment is “carved in stone”. The scrum master pushes the team to deliver their commitment and the product owner trusts on the team to actually deliver what they commited.

The commitment is all about trust and honor.

Lessons Learned?

  • Allow the team to discuss and actually understand HOW they will deliver the WHAT
  • Leave the team alone in a room – create an atmosphere of intimacy and privacy
  • The team commits to deliver – the commitment is “carved in stone”
  • Use color coding schemes for user story tasks

SCRUM & Planning1 – determine the WHAT

SCRUM Planning1: Well prepared Chaos – The WHAT.

Goal of SCRUM Planning1 is to explain the team WHAT should be accomplished during the course of this sprint.

In theory, the product owner has a well structured backlog (actually usually a spreadsheet 🙂 ) where you find user stories, estimated, already well thought-through, prioritized according to their business value and hence is very well prepared to guide the team through the SCRUM step 1 in the sprint – Planning1.

Well, after 2 years of SCRUM, we are close to there – close to – not yet there.

Initially, we had heavy struggles to get the company wide backlog setup at all. We had lots of stories in there ranging from small stories (1 to 13 story points) up to giant stories (estimated with 100 to ?) – but still in the backlog. We had stories in there with clear business value and others claimed to be “strategic”. We also had stories in there which weren’t good user stories at all (“Fixing the XYZ issue on technical element ABC”). So, we had all ingredients for a really bad Planning1 – and we had several of them. Some of them went to a point where people left the room – entirely agitated. The early days.

Now, we have product owners being on top of their backlogs and user stories. Stories being estimated higher than 13 need to be broken down into smaller pieces. Why? Experience shows that stories estimated bigger than 13 are too complex to be estimated reliably. All stories need to be estimated. Why? The team needs to know what to be expected in the Planning1 session and the product owner is forced to think-through the whole story. One point which is still tricky is the actual metric to measure business value. For the time being it’s still a mixture of our VP Product discussing with the product owners – but at least it’s an identified way to prioritize the backlog.

Lessons Learned?

  • The product owner needs to be on top of his backlog (be it the company backlog or the team backlog).
  • Stories need to be small enough to be understood fast and easy.
  • The team needs to be involved as early as possible (pre-estimation ideally).
  • You need a properly filled backlog and ideally you find a metric to measure business value in an objective way.

The agile SCRUM team – bundled forces.

The agile SCRUM team.

Besides the key roles in SCRUM, there is still this unstructured collection of humans – the team. When we started to introduce SCRUM we simply put all developers into SCRUM teams and we were finished. Amazingly, this went quite well. Developers found themselves confronted with other tasks than pure coding – but as said they did well, accepted the responsibility, improved their intra-team communication skills and everything seemed fine.

From a pure developer’s view the story could end here already. BUT (you knew there would be a “but”, right?) software development as such doesn’t contain only software development tasks – especially not in a web environment.

How to treat the non-developer resources? What about architects, user experience, visual grafix, editors, system administrators, online marketeers, quality assurance? Are they part of the SCRUM team – or not? If not, how to get them to work together with the SCRUM team?

A lot of questions! What we changed so far …

We started to structure the team. Besides the developer we have a lead developer. This person actually leads the team from a technical perspective and acts as an architect for the team. Next to the developers we onboarded the quality assurance team members to let them work directly with the SCRUM team. In parallel, we put user experience specialists directly into the SCRUM team. The visual grafix persons are still external to the team and form a service center where multiple departments of the company got access to. Members of the editorial team participate in the daily stand-up meetings (well, most of them) – but are still not part of the SCRUM teams. The system administrators are associated to the various SCRUM teams we operate – but are not actually part of the team. Online marketeers? Other departments? They are also not part of the SCRUM team and communicate mainly with the product owners and scrum masters.

So, to summarize – our SCRUM team is structured like this:

Closely connected to the SCRUM team are:

  • editorial team member

Still in other parts of the organization:

  • visual grafix designers
  • system administrators
  • other departements

Is it optimal? Well, not really – but SCRUM in our organization is a living process – we’re still improving!

Lessons learned?

  • Initially, get the SCRUM team going with the product owner, scrum master, developers and quality assurance as team.
  • In a next step when SCRUM is well accepted and adopted start thinking about a better structure for your teams.

Good ideas needed? Have a look at Marty Cagan’s great and inspiring methods and principles @

Project Manager? No need in SCRUM any more …

Project Manager? Not known in SCRUM books – hence no need for it?!?!

SCRUM in books transports the idea of “You don’t need project managers any more”. Why is it so? Well, the roles in SCRUM books – product owner, SCRUM master, team – explicitly exclude a project manager.

The project manager’s work is shared across various roles:

  • The product owner manages the backlog, prioritizes the stories and creates release plans.
  • The SCRUM master “enforces” the mechanics of the process, organizes meetings and moderates them.
  • The team takes over the detailed planning sessions and estimations.

When we introduced SCRUM we really enjoyed getting rid of all all the structures and limitations of the project work. We arrived 100% in “agile”. During our SCRUM setup days we decided to move our “project managers” into “SCRUM master”. Now with their new very limited scope of “not breaking” the new process rules. All the other duties – gone!

The Break – Working on Epics

The new modell went all well until … we started our first epic. In waterfall days the epic was called project.

After some time SCRUM works very well organizing the software development. Mainly because the process SCRUM isn’t that hard to apply and everybody likes it – because it’s agile and simple. But the overarching business planing – looking beyond the daily SCRUM work … we lost it almost entirely.

Who does the prioritization work on which project – ahhh epic – we should work next? Is it the product owner? The VP product? The CEO? The whole management team? Who takes care of the resource conflicts arising automatically if you have scarce resources? Who detects those conflicts and escalates them? How do we deal with delays?

Quite some questions. A lot of companies switching from traditional – thoroughly controlled processes to the agile modell encounter comparable issues, we learned.

How did we solve it? Well, we started to recognize that SCRUM is only one piece of the jigsaw puzzle. Furthermore, you need to work on your agile organization. Not only product development and product management are customer of your SCRUM teams. A lot of topics – owned e.g. by online marketing or customer care center – need attention as well.

In the end, when multiple departments within our organization are involved in work we started to include project managers again. They have an inter-department communication and coordination role. So, for us project managers did not disappear entirely, they showed up again in the context of strategic projects with a slightly different role.

Lessons learned?

  • SCRUM is good to organize the product development part of your agile organization
  • There is more than just SCRUM to become truly agile
  • In an agile organization you better have roles like project managers

The Product Owner – the grey eminence in SCRUM.

The Product Owner in SCRUM – the grey eminence.

When we introduced SCRUM we decided to “transform” project managers to scrum masters and turn the product managers into product owners. I talked already about how successful we were with the decision on scrum masters here. In this post, focus is on the product owner.

In the beginning, not too much changed for product managers – they still were very much focused on developing our web application – the product. They were utilizing their well-known toolbox of user testing, feature discovery, A/B testing, multi-variate testing, visual design, user experience and so on. The product backlog – one of the most important tools (according to literature) – was perceived as another list to keep up-to-date (or not).

I guess we managed to survive for roughly 2 sprints.

Where did we end? In chaos and anarchy.
The scrum masters felt accountable for the process, the framework, SCRUM. They took their job serious and the mechanics of SCRUM were easily implemented.
The product owners understood well the importance of their job – but were still occupied with getting the product management issues right. The backlog as the utmost guiding instance – the fundament of the roadmap and the release plan was simply not looked after.

Why? Well, product managers were not used to do thorough project management tasks. So far, it was okay for them to do their small-scoped planning for daily work. Now, SCRUM asks the product owner to fill the backlog, to prepare easy-to-understand stories, to get the stories into the right format to not receive 100-story-point-estimates, to do all needed lobbying with management, to inform the C-level people, to … well to take over leadership for their products. For product owners, the shift towards SCRUM was bluntly said – a shock. Product management, project management, ownership for the product business, politics, … quite a lot.

What happened? The scrum masters started to support the product owners with project management tasks – looking after the technics of longer-term project organisation. The product owners started to take over ownership for the previously mentioned tasks – firstly starting to get their product backlogs organized and cut down their stories. Then afterwards taking over responsibility from business perspective.

Where are we right now? Well, the ideal product owner is a copy of Steve Jobs – close to BEING the product. We’re still not there, however the product owners take their jobs really serious now and made quite a way to improve.

From an organization perspective, we start realizing that the product owner as the super-human being doesn’t exist at all. We think about introducing the split of having a product owner and a product manager again. The owner takes care of the organizational tasks – feeding the SCRUM process. The manager takes over ownershop of the product, the strategic development being in-line with business demand and defines the next steps to be taken by the team.

SCRUM is really an excercise! Especially living it in practice!

Lessons learned?

  • The product owner is one of the most important persons in the SCRUM / agile software development process. Be sure you pick the right people doing the job of the product owner.
  • Also, keep in mind that there might be a point in time where you need to split product owner and product manager!