Monday, November 17, 2014

Multi team sprint planning

Scrum answers the question of how one team can effectively plan their work; however it does not address how multiple teams doing Scrum can effectively plan their work. What follows is a brief explanation of the multi-team sprint planning approach that I most recently implemented for a department containing six Scrum teams.

Multi team sprint planning scale many teams scrum agile

The short version

  1. Prior to the Joint Planning Meeting the project managers perform a preliminary allocation of Epics/User Stories to teams.
  2. In the Joint Planning Meeting, each team pulls in User Stories until they are full and posts those User Stories on the Joint Planning wall. The result is reviewed by all and updated as necessary.

The longer version

Prior to the Joint Planning Meeting
  • The Project Managers schedule the fortnightly Joint Planning meeting instead of fortnightly Sprint Planning Meetings. It is held in a room large enough to provide seating and tables all of the Scrum teams is necessary. It also needs additional seating for Project Managers, Product Owners, etc. Initially the meeting was booked for 4 hours, however over time this has reduced as the process became familiar to everyone.
  • The Project Managers work with senior staff from the Scrum teams to help them understand the rough size and scope of upcoming Epics/User Stories. This allows them to roughly allocate this work to the teams. So that going into the Joint Planning Meeting each team has a backlog of approximately 2 sprints worth of work that they can pull from. Overtime the teams have become more involved in this pre-allocation.
  • The Project Managers create the Joint Planning wall in the meeting room and post up the pre-allocated backlogs.

The Joint Planning Meeting

  1. Lead Project Manager, introduces the meeting, explaining any upcoming milestones, key events and/or themes for the coming sprint.
  2. Scrum teams work to pull in size, and split Epics/User Stories are normal. Their Product Owner sits with or near them. Team members are encouraged to talk to the PMs, POs, other teams, etc, as necessary. The amount of discussion varies significantly depending on how many teams are working together / depending on other teams. Once they have their Sprint Backlog prepared they post up the User Stories on the Joint Planning wall. It is up to the team to decide to split the User Stories into tasks prior to finalising their Sprint Backlog. Once the team has posted their Sprint Backlog they are free to go.
  3. At the agreed time, all teams come back to the Joint Planning wall to review and discuss the plan for the coming sprint. This is what is shown in the photo at the top of this article. During this discussion all kinds of changes may occur work dropped, work added, work swapped between teams, dependencies uncovered, impediments noted, impediments addressed. This is the crucial element of the Joint Planning meeting.

As with all agile practices this meeting continues to evolve and change. For example some teams found the large room too noisy to hold the discussions that worked for them, hence they stayed for the initial introduction then headed off to a private room to form their Sprint Backlog before returning for the sharing and discussion.

Monday, November 10, 2014

Backlog Prioritisation Frameworks

You need to make quick prioritisation decisions that satisfy your short term goals and move you forward towards your strategic objectives. These decisions often need to compare very different types of work (e.g. Revenue generation vs. Enabling future features), which is difficult to do with discussion based prioritisation. An appropriate Prioritisation Framework will provide a simple approach to compare different types of work. 

Prioritisation is often carried out by negotiation between multiple stakeholders and the Product Owner. The negotiation occurs at different times usually between one stakeholder and the Product Owner. This causes communication overhead, confusion and triggers reprioritisation. 

Prioritisation by negotiation, as often occurs

An appropriate Prioritisation Framework will build consensus for the prioritisation decisions, hence avoiding the above mentioned issues. Here the Product Owner uses the Prioritisation Framework and associated meetings as a way to facilitate the prioritisation process and ensure that consensus is reached with the majority of stakeholders present.

How a Prioritisation Framework can streamline the prioritisation process

Scope of a framework

For items that need rapid prioritisation, such as small ongoing tasks like bugs, enhancements and tweaks to existing features; I recommend that they are handled outside of the prioritisation framework. The primary reason for this is that often those work items can be fixed faster than the time it takes to score, discuss and evaluate and analyze. 

Considerations for selecting an appropriate framework

  • The framework should be light weight & easily understandable. This will greatly assist the uptake, buy in and will reduce communication costs. 
  • The framework should allow for comparison of different types of work (e.g. Contractual vs. acquisition vs. vs. enablers for future work). None of the suggested approaches involve calculating the value of the change in $. Those calculations are complex at best, and impossible in the worst case. Instead the suggested frameworks focus on Relative Estimation over Absolute Estimation.
  • The framework should consider the rough size of each piece of work. This allows for small, medium value work items to compete with large, high value pieces of work. The end result being that we achieve a balance of quick wins and strategic goals.
  • The framework should provide a simple way to adapt the prioritisation decisions to your changing strategic needs. 
  • You need all stakeholders to buy into the framework, and agree that it will drive prioritisation. Once this is done, the framework will allow for fast decisions. If some stakeholders disagree with the framework, they will undermine the decisions that come from it. Lack of adherence, will slow down the process and cause confusion. 
  • All of the frameworks that I am about to suggest rely on gathering groups of decision makers together, so that the decision making process is transparent and fast. Gathering all of the appropriate decision makers may be a tough ask in some situations.  

Possible Framework - Value & Size Comparison 

Value is determined via Product Owner group applying absolute estimation highest is more valuable. Size is determined via Delivery Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. The changes are then mapped onto the matrix below, which leads to discussions on priority.


  • Subjective value measurement is open to emotion / rank over taking the real value.
  • Value is a very simplistic representation, which makes it difficult to compare changes of differing types. i.e. Customer Retention vs. Technology Enabler.


  • Simple, easy to understand and communicate.
  • Uses group consensus for both Value and Size, which builds acceptance of the decisions.

Possible Framework - Money Voting

A simplistic voting approach. It subconsciously makes the participant consider the relative real world value of each change.   

Each stakeholder is given a sum of imaginary money (say $100) which they are asked to distribute amongst the items on the backlog. Priority is then judged by the sum raised by each item.


  • Subjective value measurement is open to emotion / rank over taking the real value.
  • If ‘spending’ is done in the open, whoever goes first can set a precedent and whoever goes last has more power to influence the final outcome.
  • Can be time consuming if done in private, as different stakeholders will respond at different times. They may also delay waiting to see how over stakeholders are spending their money.
  • Does not include size; however it would be simple enough to divide the Total Score by Relative Size.


  • Simple, easy to understand and communicate.
  • Quick if done in the open, but has the Cons related to influence.

Possible Framework - Weighted Shorted Job First (WSJF) from SAFe

Documented in Scaled Agile Framework (SAFe), based on work in Don Reinertsen’s book ‘The Principles of Product Development Flow’ as explained here

Higher WSJF indicates higher priority.

User, Business Value, Time Criticality, Risk Reduction & Opportunity Enablement are all determined via Product Owner group applying Relative Estimation, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable. 

The value of User, Business Value, Time Criticality, Risk Reduction & Opportunity Enablement are estimated by the Product Owner group in turn. To do this they select the work item with the lowest User/Business Value and assign it 1. The other work items are estimated by applying Relative Estimation, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable. The Product Owner group then moves onto Time Criticality and repeats the process. Finally they do it for Risk Reduction /Opportunity Enablement.

Size is determined via Team Leader / Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. This is a stand in for duration. WSJF really calls for duration of the job not size but size is usually a very good substitute.


  • Cost of Delay is difficult to explain
  • Assumes that there is equal importance between the three key criterion (User/Business Value, Time Criticality & Risk Reduction/Opportunity Enablement. This may not match the needs of the business.


  • Financially sound approach (minimising cost of delay).
  • Purely relative estimation approach, each round of estimation is only using the current projects to help determine priority.
  • Uses group consensus for both Value and Size, which builds acceptance of the decisions.
  • Removes some emotion from prioritisation process.
  • Allows for comparison of different types of changes.

Possible Framework - Prioritisation Matrix

This comes from the model documented by University of Wisconsin-Madison

Higher score indicates higher priority.

An agreed set of Criteria (with scoring notes) are selected for use in the framework. Each Criterion is given a weight relative to the other criteria. These criterion and weights do not change. 
Criteria Scores are determined via Product Owner group absolutely rating each change on the scale of 0 to 9, using the Scoring Values for guidance. 9 is the highest value. These scores are then used to calculate the total score.

It is best explained with an example.


  • Does not include size; however it would be simple enough to divide the Total Score by Relative Size.
  • It could be difficult to gain acceptance of the criteria scoring system and weightings.
  • Uses rating (matching up to the scoring values) instead of Relative estimation.


  • Customisable criterion, enable the prioritisation matrix to match the business needs.
  • Uses group consensus for Value, which builds acceptance of the decisions.
  • Removes some emotion from prioritisation process.
  • Allows for comparison of different types of changes.
  • A key benefit of this is that everyone understands the main company goals and is motivated to come up with features that push the scoring up.

Possible Framework – Customised WSJF Framework

A combination of WSJF with a customised Prioritisation Matrix. This is what I would usually recommend.

Higher Score indicates higher priority.

Similarly to WSJF the Product Owner group estimates each criterion in isolation; however the list of criterion is an agreed list of criterion similar to the Prioritisation Matrix. They start with the first criterion, select the work item with the lowest value and assign it 1. The other work items are then estimated relative to the first item for the current criterion, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable. The Product Owner group then moves on the next criterion and repeats the process, until all criterions have been completed.

Size is determined via Team Leader / Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. This is a stand in for duration. WSJF really calls for duration of the job not size but size is usually a very good substitute.

To keep the process quick I recommend that a maximum of 5 criteria are selected. I would start with:

  1. Constraints – Time constraints, Regulatory constraints.
  2. Customer Joy – delighters, differentiators.
  3. Revenue – conversion rates, income, projected income.
  4. Risk Reduction / Opportunity Enablement (RR OE) – Increase redundancy, reduce technical debt.

Other suggested criteria to consider

  • Strategic Alignment – matching the company’s strategy goals.
  • User Impact – high number of user or small number of key users impacted.


  • Cost of Delay is difficult to explain
  • It could be difficult to gain acceptance of the criteria scoring system and weightings.


  • Financially sound approach (minimising cost of delay).
  • Purely relative estimation approach, each round of estimation is only using the current projects to help determine priority.
  • Removes some emotion from prioritisation process.
  • Allows for comparison of different types of changes.
  • Customisable criterion, enable the prioritisation matrix to match the business needs.
  • Uses group consensus for criterion, which builds acceptance of the decisions.
  • A key benefit of this is that everyone understands the main company goals and is motivated to come up with features that push the scoring up.

An example again helps to explain it.


It is rare that I suggest adding more process. However when dealing with the kinds of situations that can come up when prioritising work for several teams with, many competing stakeholders to deal with  some process is a good thing.

Sunday, November 2, 2014

Promoting constructive discussions in Retrospectives

When transitioning to agile from a strong command and control environment, many team members say as little as possible in Retrospectives. They are used to being told what to do, and do not want to seem like the ‘trouble maker’ by pointing obvious issues. Over time they will realise that it is a good (and safe) thing to point out issues so that the team can work on solving them. 

The scope of what they could change in the past was very limited, which compounds their reluctance to speak up. Usually it takes a while for them to realise that the scope of what they can now change is vast. The task board is quiet often seen as something the team owns and due to its highly visible nature is one of the first areas that teams start to make changes. After the team has implemented their first couple of changes, the Scrum Master should explain to the team just how big their scope for change through Retrospectives really is. 

To aid the explanation of scope and to help bring out information from quiet team members the following list of questions is often useful. For the Scrum Master it will be worth reading these questions prior to each Retrospective and working out which questions could be used to prompt discussion.

Delivery / Completion

  • Why did the extra tasks appear in the sprint? 
  • Why were User Stories/Tasks not completed?
  • Why were some User Stories/Tasks, only partially completed?
  • Did the team over commit? 
  • Was the team reliant on one person/skill set to complete a task? 
  • Were any milestones missed?
  • Were last Sprint Retrospective actions items completed?
  • Where our estimates accurate? Both Story Points and hours?


  • What was the quality of work produced like?
  • Was the test coverage (both automated and manual) sufficient for our needs?
  • Did our documentation provide the information that we required to complete our jobs?
  • Did rework hold us back this sprint?
  • Did the Review/Demo make you proud to be a member of this team?
  • What was the cause of the bugs/tickets that we worked on this sprint?

Scrum / Continuous Improvement

  • What did everyone work on immediately after the Planning meeting? Why did people work on items other then high priority User Stories?
  • Was the Product Backlog ready for use at the planning session? Prioritised, estimated, enough detail?
  • Did the Burndown Chart realistically represent the progress of the team?
  • Did everyone view the Burndown chart as useful?
  • Were last Sprint Retrospective actions items beneficial?
  • How did everyone contribute to User Story value?
  • Is everyone happy with how the Stand ups are working? Can they be improved?
  • Is everyone happy with how the Reviews are working? Can they be improved?
  • Is everyone happy with how the Retrospectives are working? Can they be improved?
  • It has now been X sprints that we have been using Scrum, do we think our situation is better or worse since starting? What is better? What is worse?
  • Why were low priority tasks being worked on, while high priority user stories were on hold?

Communication and Team work

  • Was everyone clear on the team goals?
  • Was everyone clear on their personal priorities?
  • Did internal knowledge transfer occur in a timely and effective manner?
  • How was the team internal communication? Was it clear, concise and timely?
  • How was the intra-team communication? Were expectations and dependencies clear?
  • Did anyone have difficulties obtaining timely information/assistance from people outside of the team? I.e. Product Owner, external Technical Expert.
  • Did anyone have difficulties obtaining timely information/assistance from people in the team? I.e. Architect, Test Specialist, Documentation Specialist, Scrum Master, etc.

Photo Credit:

Sunday, October 19, 2014

Funnel Task Board helping agile teams deliver more

Many agile and Scrum teams struggle to limit their work in progress. This results in task switching, delays and other wastes, overall reducing how much the team delivers. Physically limiting space on a team task board asks as a mental barrier. This can be used to limit their work in progress and hence deliver more. I have had good success with Funnel Boards. The User Stories fall from the backlog into one of three spots available in the funnel for User Stories. It is a simple and effective way to limit the teams WIP. I heard of Funnel Boards at Agile Tour London 2013.

Zombie Team, Funnel Task Board
Zombie Team Funnel Board
The funnel board, leaves plenty of space around the edges for avatars, notes and other visualisation.

An empty Funnel Board

Funnel Task Board, empty, limiting WIP

The backlog at the top, is the Sprint Backlog. It is populated during Sprint planning and empties out as the Sprint progresses. Hopefully it is empty at the very end of the sprint.

Work flows from top to bottom

Funnel Task Board, flow, limiting WIP, limited WIP, lean, scrum, agile

As one of the three in progress stories is Done, the next story from the Sprint backlog flows down into the available spot.

A simulated sprint in progress

Funnel Task Board, flow, limiting WIP, limited WIP, lean, scrum, agile

Saturday, October 11, 2014

Waterfall Iterations softening resistance for the transition to Scrum

Switching from traditional waterfall development to Scrum is a very big mental change for many people. These people can be resistant to the change and potentially lead to a failed transition. It you have detected resistance to the transition to Scrum, before making the big change, consider an intermediate step to ease everyone into Scrum and lower the resistance to change. Consider changing to ‘Waterfall Iterations’ for a while before moving to Scrum.

waterfall iterations

When faced with transitioning from traditional waterfall development to Scrum, there are many unknowns and misunderstanding to be overcome. In some organisation this breeds significant resistance to the transition. If left unchecked this resistance to change can derail the whole transition. It is a great idea to find out what unknowns and misunderstanding exist and deal with them one by one. However that approach is not scalable and some issues will remain as the switch over looms. 

What I have used and seen to be successful in change resistant organisations is to stage the transition. Teams change from Waterfall to Waterfall Iterations for a couple of months, then the switch over to Scrum. Teams can be switched over a couple at a time, so that they can learn from and support each other. There is a co-ordination cost to having teams operating in different approaches; however it is generally worth it to smooth out the transition.

Waterfall Iterations

This phase introduces everyone to Iterations, co-location, cross functionality, Product Owners and Scrum masters. 

  • Cross functional, co-located teams of 5 to 9 people.
  • Teams use Sprint Retrospectives, Task boards, Burn-downs and Daily Stand-ups just as in Scrum. 
  • Iteration planning occurs every two weeks, where the Product Owner works with the team to pull in work items that have been created by whoever in waterfall created/allocated work items.
  • Iteration Review occurs every two weeks where the team demonstrates their completed work items to the Product Owner.
  • Functional testing carried out by the team with in the Iteration.
  • System testing carried out by separate testing team, outside of the Iteration.


The switch to Scrum from Waterfall Iterations; focuses teams on completing (including System testing, deployment) User Stories, that they themselves have created, split and sized.

A note

In organisations where there is strong support for the transition (or even only light resistance) I would recommend switching straight to Scrum.

Another note

Kanban is an evolutionary process improvement approach that dramatically reduces resistance to change. That is another option to consider.

Photo Credit:

Sunday, October 5, 2014

Choosing the correct type of feedback can improve your coaching

Helping people to grow and improve is very satisfying. Hence constructive and re-enforcing feedback seems natural to me and I use it often. However there is a continuum of behaviour that prompts me to give feedback and unfortunately it should not always result in re-enforcing feedback. The feedback approach coaches’ use should change to suit the type of behavior we are providing feedback about. Choosing the correct approach is crucial in effecting the outcome that will help the individual, team and yourself.

observed behaviour continuum feedback type style behavior

Adjusting feedback

Use Adjusting or Corrective feedback when someone is doing something that they must stop, or must change. I.e. Their behaviour is destructive, career limiting, negatively affecting others.

  • Do prepare (gather specific examples of the behaviour, talk to peers, draft what you will say, practice what you will say)
  • Do follow a structure and be directive in your delivery. Here is a template that you can use: it has been observed here, here and here, that you are doing X which is causing Y, this behaviour needs to stop, because it is causing Z. If the situation comes up again please do A instead.
  • Do give this feedback is private.
  • Do not give this feedback immediately after the event. Make sure you wait until everything has calmed down, so that it can be talked about in a rationale and deliberate manner.
  • Do not combine with other types of feedback, as it sends mixed messages.

Constructive feedback

Constructive or developmental feedback should be used when helping some to do better, or to help them see opportunities that they missed. 

This is covered in combination with Re-enforcing in my article Coaching Scrum Masters. The feedback sandwich puts two slices of re-enforcing feedback around a sliver of Constructive feedback. I have found this approach to be highly effective and have received plenty of positive feedback about it.

Re-enforcing / Encouraging feedback

Use it to praise people for effective behaviour and encourage them to do more of it, and perhaps do it even better next time.

  • Can be given in public (as it publicly promoting the behaviour that is appropriate), however be aware of who you are giving it to, some people will be embarrassed through to down-right upset at public acknowledgement. 
  • This type of feedback should be approached as discussion with the recipient. You are not telling them to repeat their behaviour you are merely discussing the benefits that you noticed and that you would like to see more of that behaviour.

Sunday, August 10, 2014

Ideas for tasks when splitting or planning your User Stories

After years of working in a command and control culture moving to an agile methodology feels liberating for many team members. Unfortunately it can also feel over whelming. The first time a team needs to plan their iteration for themselves the can struggle to think of appropriate (and importantly small) tasks to split their User Story into. What follows is a list of ideas that I use with new teams to open their eyes to some of the options they have available to them.

Additionally of the following information is available on this one page PDF cheat sheet.

Cheat sheet for splitting or planning User Stories into tasks


  • Clarify Product Owner expectations
  • Product Owner early feedback
  • Product Owner review 
  • Confirm all Acceptance criteria

Shared Understanding

  • Scenario workshop (Three amigos)
  • Design session
  • Test creation session
  • Meet with customer representative


  • Design review 
  • Refactoring of existing code
  • Interfaces created
  • Code / Implementation
  • Code reviewed
  • Unit tests
  • Unit tests reviewed 
  • Defects resolved 
  • Defects retested 
  • Code merged 

Quality Assurance

  • Functional test plan created 
  • Functional test plan reviewed 
  • Functional test plan executed 
  • Automate functional tests 
  • Identify tests for automation
  • Exploratory testing
  • Regression Test Suite passes 
  • Continuous Integration passes
  • Deployment Tested
  • Performance tested


  • Deployment instructions
  • Internal Processes / Guides
  • External Processes / Guides
  • User story – notes, history, plan
  • High Level design
  • Design decisions
  • User Manual
  • Help
  • ‘How to’ Guides 


  • User Story updated in tracking tool 


  • Script/Run-sheet updated 
  • Data prepared 
  • Demo automated
  • Deployed to demo environment 
  • Practice run

Agile Coach Competencies

When thinking about how I could further improve my skills and knowledge as an Agile Coach, I came to the question of ‘How does an Agile Coach differ from a Scrum Master?’ Both provide coaching and work in agile, hence any division could appear to be very arbitrary. Writing out the competencies that I feel a good Scrum Master should have and then the competencies a good Agile Coach should have helped me answer the question. One good way to split the roles; is to look at what they focus on.

If I assume a Scrum Master is someone focused on providing Servant Leadership for a single team or a couple of teams. Than an Agile Coach is someone who focuses on coaching the department (and/or company) that those teams exist in. The Agile Coach provides training and coaching that is aimed at delivering value across the department/company, not just the team level. Sure a Scrum Master can do this, however it is not their focus when there are Agile Coaches and Scrum Masters in the same company.

With all of that in mind, I have updated my post on Scrum Master Competencies, and I present the competencies that I want a good Agile Coach to have.

The information presented below is available as a two page PDFcheat sheet.

Agile Coaching Competencies cheat sheet

Competencies of a good Agile Coach

These competencies assume that the person already has most of the Scrum Master Competencies.


* Adaptable
* Persistent
* Observant
* Unassuming
* Inquisitive


* agile Manifesto
* Scrum
* XP
* Lean 
* Kanban
* Agile Fluency Model
* Declaration of Interdependence

Scaling Approaches

* Scrum of Scrums
* Lean PMO
* LeSS 
* SAFe 

Change Management

* Iterating towards agility
* Questioning to encourage action
* Create broad network of contacts
* Building strong relationships
* Crucial Conversations
* Fearless Change Patterns
* Kanban Method
* Kubler-Ross change curve
* Kotter’s 8 step model
* Lewin's model
* McKinsey 7-S model 
* ADKAR model
* Schein's organizational culture model
* Appreciative Inquiry


* Dangers of metrics
* Lean metrics
* Visualising metrics
* Personal KPIs
* Team KPIs

Thinking Tools

* Queuing Theory
* Systems Thinking
* Theory of Constraints

  • The Five Focusing steps
  • Current reality tree
  • Evaporating Cloud


* Questioning for realisation
* Questioning to encourage action
* Creating SMART goals
* GROW model
* FUEL model
* Neuro-linguistic programming 
* Body language to control the mind
* De-stressing techniques
* The Responsibility Process 
* Working with resistant people

Training / Teaching

* Reading the audience
* Keeping energy levels up
* Kolbs learning styles
* Learning Modalities
* Fleming's VARK model
* Games for learning
* Run Dojo’s
* Run Lean Coffees
* Run World Cafes
* Competency Based Training
* Creating training material
* Creating games


* 30s elevator pitch for agile
* Exhibit passion


* Interviewing Techniques
* Competencies to look for


* Awesome emails
* Excellent written
* Creating memorable presentations
* Presenting
* Using appropriate medium


* Backlog Prioritisation Frameworks

* Multi Team Boards
* Traditional Iron Triangle
* Agile Iron Triangle
* Release burn-ups
* Feature / Traffic Light charts
* MoSCoW categorisation


* Facilitate large groups
* Facilitate senior managers

Collaborative engagement techniques 

* Impact Mapping
* Value Stream Analysis

Self Development

* Experiment at work
* Self reflection
* Attend Meet-ups
* Attend Conferences
* Read Books, Articles, etc.

Motivating Others

* Autonomy
* Relatedness / Purpose
* Mastery
* Detractors / Inhibitors

Distributed Development

* Models
* Communication
* Engagement
* Technical Practices

Agile Contracts

* 10 types
* Building trust

Your Thoughts

Have I missed anything? 

Is there any that you disagree with?

Related Articles

Sunday, July 20, 2014

Co-ordination < Cooperation < Collaboration

This is one way a work group can improve their interactions and hence become a high performing team. Individuals and Interactions are crucial for a team to have a chance of being a successful agile team. I often see teams that are full of great individuals yet the team is not performing as well as they could be. One common cause of this is that they are all working as individuals and not interacting effectively. These work groups can become great teams by progressing themselves from Co-ordination to Cooperation to Collaboration. 


Three people coordinating their work across three tasks on three User Stories

Dictionary Definition: the organization of the different elements of a complex body or activity so as to enable them to work together effectively.

The working definition I use: Pursuing individual success over team success, by staying well out of each other’s work. i.e. Team members working on separate user stories within the same iteration. 

Symptoms at Stand ups: 

  • Many user stories in progress.
  • Reporting their status to the ‘leader’, not the team.
  • No interest in user stories that are not their own.
  • No concern regarding delivery of user stories that are not their own.


Three people cooperating while working on three tasks on one User Story

Dictionary Definition: the action or process of working together to the same end.

The working definition I use: Pursuing team success, by working as individuals. i.e. Team members working on separate tasks within the same user story. 

Symptoms at Stand ups: 

  • Few user stories in progress
  • Present their information to the team.
  • Asking questions about user stories that they are not working on.
  • Interest in the delivery of user stories that they are not working on.
  • Rushing to select the most interesting tasks for themselves. 
  • Rarely offering to assist each other.


Two people collaborating on one task, while another cooperates by working on another task all for the one User Story

Dictionary Definition: the action of working with someone to produce something.

The working definition I use: Pursuing team success, by working as one. i.e. Team members working on the same task within a user story. E.g. Test Scenario workshops, design workshops/sessions, pair programming, pair testing.

Symptoms at Stand ups: 

  • Few user stories in progress
  • Present their information to the team.
  • Regularly offering to assist each other, especially when a user story is at risk.
  • Requesting the team input into selecting the next task that will best help the team achieve its goal. 
  • Regularly offering to pair with each other, and regular acceptance of those offers.
  • Useful discussions often break out. It is sometimes hard to keep the stand up short because there is some much input and interest is effective plans and strategy.

Collaboration improves creativity

Effective collaboration results in something far greater than any contributor could achieve by themselves. Here are some creative collaborations, were I believe the result was superior to the input of any individual: Monty Python, Pink Floyd, The Beatles. They all bounced ideas off each other, helping each other to reach great heights. When separated they were all still great individuals yet failed to reach the dizzying heights they reached when collaborating.

Collaboration improves reviews

It is hard to provide an effective review without in-depth understanding of the work being carried out. That is why it is difficult and sometimes ineffective to review each other’s work when team members are just cooperating with each other. When team members collaborate with each other they are able to review as they progress, and/or review the work with deep understanding that results in superior feedback and hence a superior result. 

Collaboration improves planning

Planning is only as good as the input it receives. When team members are collaborating they are more invested in the work, and hence more motivated to provide input. Additionally they are more motivation to ask the tough questions at stand ups, that help teams deliver when the going gets tough.


Team members should aim to always be Cooperating and often be collaborating. 

Thursday, May 29, 2014

Don't start your Sprint or Iteration on Monday

Monday seems like a logical time to start your Sprint, right? The start of the calendar week, rested after the weekend, let’s go! In reality it is a bad idea, and I will explain why…

Start/Finish line

Primarily it comes down to interruptions to the sprint cadence. The start and finish days of a sprint are the days where it is crucial that the entire team is in attendance. Everyone needs to know what we are doing, why, and to learn together from our mistakes.

Public or Bank Holidays usually occur on a Monday. If your sprint is scheduled to start on a Monday, which is also a Public Holiday, you need to reschedule all of the sprint meetings, shorten the sprint and this causes significant admin overhead and critically it interrupts your cadence. The other issue that often occurs is the impact of changes arising from Monday morning management meetings.  These changes hit the team just after they have started their sprint, resulting in re-planning costs, and a diminished sense of autonomy.

Fridays are bad too as this is often the day that people book off to extend their weekend into a mini break. Fridays are often the day that leaving lunches, leaving drinks and other celebrations occur, resulting in more impacts.

So instead of Monday, start your sprint on Wednesday or Thursday. The sprint end/start being the middle of the week has several advantages. It avoids the issues of Monday/Friday. Meeting rooms are generally more readily available in the middle of the week.

I do not recommend Tuesday because when there is a public holiday on Monday the sprint will effectively be ending the Friday before a long weekend (which is when everyone is mentally checked out).

So in summary avoid Mondays and Fridays it will save a lot of heart ache.

Photo Credit: Andrew_D_Hurley via Compfight cc

Tuesday, April 1, 2014

Scrum Master Competencies

The Scrum Master is a complex, challenging and rewarding role. Consequently they need to develop a broad range of competencies. A diverse skill set will allow them to succeed; no matter what the world throws at them and their team.

What follows is the list of competencies that I believe a great Scrum Master / agile Iteration Manager should develop over time.

Tree of competencies

August 2014: I updated list in conjunction with adding my Agile Coach Competencies blog. Additionally a two page PDF cheat sheet of Scrum Master Competencies are now available.

Scrum Master Competencies cheat sheet

Organising the Team

* Knowledge of Scrum rules
* Communicating internally
* Communicating externally
* Up to date Team level documentation
* Reporting team status
* Involving whole team in Sprint planning

  • Setting clear elevating goals
  • Appropriate commitment level
  • Ownership of the commitment
  • Adjustment of the Sprint Plan

* Provides Clear Direction 

  • Set clear and elevating goals
  • Balances conflicting team priorities
  • Focuses team on delivering priority/valuable items
  • Limits team WIP

* Dealing with impediments

  • Identifying impediments
  • Resolving team impediments
  • Resolving cross team impediments
  • Appropriate Escalation

* Effective Facilitation

  • Outcome focused Meetings
  • Time Boxing
  • Adjusting to different situations
  • Dealing with Difficult people
  • Observe while participating
  • Be Participant and Facilitator
  • Create safety
  • Root Cause Analysis

* Using Collaborative engagement techniques 

  • Planning Poker
  • Fast Estimation
  • Visual Planning
  • Dot Voting
  • Story Maps
  • Brainstorming
  • Cause Effect Diagrams

Improving the team

* Managing Technical Debt
* Establishing a good Team Culture

  • Celebrate successes
  • Social bonding
  • Supporting each other
  • Promotes cross skilling
  • Let’s the team experience failures

* Improving team members

  • Providing Feedback
  • Motivating 
  • Coaching
  • Teaching

* Using Agile Technical Practices

  • Refactoring
  • Agile Testing
  • Test First
  • Test Driven Development
  • Acceptance Test Driven Development
  • Continuous Integration
  • Pair Programming
  • Simple Design

* Using Continuous Validated Learning 

  • Plan, Do, Check, Act
  • Designing Experiments
  • Collecting & using Data
  • Safe to Fail
  • Varied Retrospective Approaches

* Leading change

  • Effective Retrospectives
  • Influence without authority
  • Challenging the status quo
  • Kaizen / Continuous Improvement
  • Celebrate successes

* Using Lean principles in decisions

  • Eliminate waste
  • Build Quality in
  • Create Knowledge
  • Defer Commitment
  • Deliver Fast
  • Respect People
  • Optimise the whole

Establishing a Self-organising team 

* Exhibit Servant leadership
* Exhibit Scrum Values
* Using Agile Principles in decisions
* Ownership of team commitments
* Making it visible & get the team to take action
* Get team to identify and remove impediments
* Involving whole team in grooming / design
* Involving whole team in medium term planning
* Encouraging ‘leaders’ within the team
* Do yourself out of a job

Thinking Big

* Basic medium term planning
* Visualise teams medium term progress
* Ownership of Department level commitments
* Optimising the whole

  • High level knowledge of medium term plan for all teams
  • Volunteering to help other teams

* Communicating with other teams 
* Identifying and resolving cross team impediments
* Improving cross team Technical Practices
* Recording appropriate feature information for future teams
* Up to date Department level documentation
* Up to date Company level documentation
* Improving other Scrum Masters and POs

  • Providing Feedback
  • Motivating
  • Supporting


* Balances Responsibilities of SM, Team Contribution, Self-Development
* Learns by reading / researching
* Learns by experimenting / doing
* Learns by discussing
* Coachable

User Stories

* Formats
* Personas
* Splitting Approaches
* Vertical Slicing
* Sizing

Other Characteristics

* Patient
* Assertive
* Self-Starter
* Organised

  • Prepares well for meetings

* Consistent
* Understands people

Getting Team Based Results

* Team delivering consistently
* Team regularly finishing their top priority stories first 
* Team regularly finishing >=33% of stories prior to the Sprint half way mark 
* Team and PO collaborating extensively on stories (planning, splitting, design, implementation, verification)
* Team not building up inappropriate Technical Debt
* Retrospectives regularly result in positive changes
* Innovation is occurring

Your Thoughts...

Have I missed anything? 

Is there any that you disagree with?

Photo Credit: angus clyne via Compfight cc