Professional Documents
Culture Documents
There are many lists of coaching techniques; the following is fairly a fairly comprehensive list but exhaustive:
The 5-minute pre-session Check-In – Let your clients complete a short questionnaire before each
coaching session. This helps both you and your clients to recognize their progress and success since the last
session. You’ll find out if there were roadblocks and what they’ve been struggling with. It shows you what
bothers them most at the moment and what they want to focus on during their next session.
Use the SMART goal setting technique in your coaching – SMART goal setting stands for Specific,
This technique brings a clear structure into goals. Each goal or milestone comes with clear and verifiable elements
instead of vague resolutions. The broad goal of “I want to grow my business” will be described in much more
detailed and action-oriented steps by the client. The SMART goal could be: “I will win five new clients for my
business this month by asking for referrals, creating two useful blog articles and social media networking”.
Let clients write down and share the gold nuggets after each session – Encourage your clients to share
their gold nuggets from each session with you; it leaves them with a clear picture of how much value they
It’s easy to help them get going with just a few simple questions like: “What was the most valuable takeaway from
this session?”. This coaching technique helps you to find out the client’s “A-ha” moments and to avoid
misunderstandings.
If all these notes are organized in a shared stream that is accessible to both you and the client you can reread and
recap these nuggets any time at later stages during the process.
Ask open-ended questions – Open-ended questions allow your clients to include more information,
including feelings, attitudes, and understanding of the subject. This allows the coach to better access the
Use the power of writing – Writing down plans and goals is the first step towards making them a reality.
It commits your clients to act, especially when they are shared and recorded with someone else (like with
A study with two groups has shown that people who write down goals and make a weekly progress report achieved
their goals at a rate of 76%, whereas the participants of the group who didn’t write anything down achieved their
Be fully present and focused – Take two minutes for yourself and breathe calmly before each session.
Once your meeting has started, try to avoid distractions and give your clients undivided attention. Show
your genuine interest and that you really care. This may sound self-evident but is an important step toward
Follow-Up with the client – Use regular questionnaires where clients share their progress, experiences,
This ongoing feedback as a follow-up between sessions is a perfect way to monitor and evaluate the effectiveness
of the coaching. It shows your clients that you really care about their progress and gives them the feeling they’re
The coaching journal of progress – A regular progress and reflection journal helps your clients to
A coaching journal is similar to the ongoing feedback described before. Your clients can write down their emotions,
experiences, observations, challenges, success, thoughts, and feelings. They don’t have to wait until the next
sessions which might be in a week or two but can share what’s on their mind right at the moment where it happens.
A shared journal gives your clients the feeling that you’re always there for them and “listening” without the need
for your presence. They can write whenever they feel like it; at night, in the morning, during the day, at the train
station on the way to their workplace or while waiting for the doctor.
A coaching journal gives them the ability to focus on themselves only without any time pressure or distractions.
Once written down they can always reread and recap prior entries at a later stage of their process. Once these
thoughts are shared with you you’ll gain invaluable information that will take your coaching and mentoring to the
next level.
questionnaire or action item. They all support the work you’ve been doing within a coaching session. They
help clients to reflect, act and achieve necessary milestones towards their bigger goal.
Homework helps to see if and how the plans from each session are being applied; it helps clients to keep the focus
1. The GROW model – The GROW model is a simple method for goal setting and problem-solving in
2. G for Goal: The goal is what the client wants to accomplish. It should be defined as clearly as possible.
3. R for Reality: That is the status quo, where our client is right now. The client describes his/her current
4. O for Obstacles and Options: What are the obstacles (roadblocks) that keep your client from achieving
the goal? Once these obstacles are identified you can find ways to overcome them – the options.
5. W for Way forward: Once identified the options need to be converted into action steps that will take your
6. A Shared To-Do list – The client commits to various action steps and plans during the coaching sessions.
Once they write down and share these ‘to-dos’ with you they actually put them into existence; they become
like a contract between you and the client and strengthens their accountability.
Another benefit is that both of you know what is getting done and what isn’t at any moment during the process.
You immediately see where they procrastinate or struggle and when your support is needed. The shared to-do list
helps to set priorities, achieve milestones faster and keep track of the small wins during a coaching process.
“My goal is achieved” – It is a great thought experiment if you ask your client to exactly describe a
It shouldn’t be just a vague description but a whole day from start to finish:
This technique will encourage the client to use his/her positive imagination and visualize what he/she truly desires.
Afterward, you can work together to get the actual steps to that “miracle” where the goal is achieved.
Use every session to become a better coach – Every single session offers you the chance to become a
better coach. Take five minutes immediately after your client left and write down some thoughts; you can:
Think about methods and techniques you used in the session and how they worked
Think about something you would do differently if you could “replay” the session?
What are the recommended ways to handle change in requirements during the middle of the sprint?
This is a very common scenario seen in the projects which are using Scrum Approach. The team should always be
prepared for that. But try to have a good conversation with the Product owner to not include in the current sprint
and deferred to the next sprint. Changes in requirements sometimes taken as feedback from the customer so that the
As a tester, they should take the generic approach by writing the generic test cases (Login screen, user credentials).
Till the requirements are stable, try to wait if you are planning to automate the test cases.
As a developer, the same approach can be used where chances of changes are minimal. Try to code using design
patterns and oops concepts (Components or package independent of each other), so that change in one component
The selection of the iteration length should be guided by the following factors:
It means that if the team is working towards a release which is three months away, one-month iteration will give
The general rule of thumb is that any project will benefit from at least 4-5 opportunities to get feedback. So, if a
project overall duration is 5 months above then it is worth to consider 4-week iteration. Otherwise, 2-3 weeks
When there is a great amount of uncertainty about the work to be done then short iterations will allow to get more
Choose an iteration to maximize the value of feedback that can be received from inside and outside the
organization.
If there are chances of change in priorities then it better to go for short iterations. If we are going with long
iterations and there is some change in requirement then we need to wait for 4 weeks to implement them.
There is a cost associated with each iteration as each iteration should be fully regression tested. If this is costly, then
As long as the end date of a project is far in the future, we don’t feel pressure and work leisurely. The point is not to
put the team under more pressure. Rather, it is to take the total amount of stress they normally feel and distribute it
evenly across a suitable long iteration.
There are still a few challenges which the Scrum team face during the development phase.
During the development, some field issues or high priority bugs come up.
Difficult to change the mindset of management from the traditional model to Agile.
Some development efforts don’t easily fit into a time-boxed sprint. Therefore, Scrum doesn’t work for me.
This is a real problem. Several kinds of development resist being meaningfully squeezed into standard size
Database ETL requiring extract, cleanse, transform, stage, and present data
Developers accustomed to working autonomously may find that Scrum is unnecessary and slows them
down.
Distributed team-Communication is the core issue among distributed teams. Different time zones and
conflicting working hours may impair overall effectiveness, and collaboration may be difficult in some
cases.
Though there are so many challenges, there are ways to handle each and every situation and deliver a quality
5.
Can there be multiple teams for the same project? How to manage it?
Yes definitely there can be multiple teams for the same project. For example, the UI team, Service layer team, etc.
The team can be feature teams or component teams and can be geographically distributed.
Scrum Master role is very challenging in this type of multi-team handling collaboration and coordination. The
reason is the time gap between two different teams which makes it even more challenging.
But there are many ways by which it can be handled. There are 2 suggested frameworks available
It recommends multiple teams with the same product owner with multiple sprint backlogs but with one product
backlog.
Process-wise LeSS is same as that of scrum but with slight modification. Sprint planning is split into two parts. One
planning consists of representatives from all the teams where the team decides about “WHAT” the Product Backlog
items to be built in the next sprint. The second planning meeting will be done by the individual team about how the
Similarly, retrospection can be a help in 2 parts. One which is common to all the whole project team and one with
the individual team so that the focus can be on individual team issues and work towards them to resolve them.
1. When you need to coordinate with hundreds or thousands of people in a big organization. SaFe is the
recommended framework.
2. When the transition from the Component level team to feature level team is difficult.
SaFe makes it easy even to handle the component level team through RTE and Program Board.
How to coordinate?
Scrum of Scrums: This is one of the meetings which happens daily with all the scrum masters and chief Product
Owner can facilitate it. It is the same as that of daily scrum but the focus is on a team level.
Each team sends out one member to participate and answer the following questions:
Common Retrospectives.
Sprint Scheduling-All the teams can start and ends at the same time. But there can be a difference in that also. It
makes our coordination and communication easy. They can also have 1-2 days gap in starting the next sprint which
estimation should be used like Planning poker, shirt size estimation, etc. If story points are used all teams have to
What are the different stages of a team will go through the group development?
Every team will go through 4 stages of group development which is Forming, Storming, Norming and Performing.
Forming- Most team members are new, polite and humble in this stage also the roles and
roles and responsibilities, their work or some other issues. Retrospection there will be a huge
qiosk. Everybody has their own working style due to which there will be a conflict between many
team members due to different sorts of reasons. This is where the team fails.
Norming- In this phase of development people start resolving their issues, differences and start
appreciating their colleagues for the work. This is a very good stage as the team is moving
Performing- In this phase, the development team has one sprint goal and they all work towards it,
this is where hard work pays and the project is released with the best quality. It is easy to be part
of such a team where any disruption will not alter their sprint goal.
What is refactoring?
Ron Jeffries says: In Agile, the design must simply start simple and grow up. The way to do this is refactoring.
Refactoring refers to changing the structure but not the behavior of the code. For Example: Suppose in the code
base we have two methods and each has 3 identical statements. These statements can be extracted from this code
and put it into some new method and both these methods can call the new method. This refactoring slightly
improves the readability and maintainability of the program as the duplicated code is moved to a new place. There
are so many tools available with which you can run in your code base and it will help you in finding out the
duplicity of code. In this way, the structure of the code is changed but not the behavior.
Refactoring is not only crucial to TDD but it also helps prevent code rot. Code rot is the typical syndrome in which
a product is released its code is allowed to decay after a few years then an entire rewrite is required. By constantly
refactoring and fixing small problems before they become big problems, we can keep our applications rot free.
When a refactoring opportunity is identified have a conversation with product owners and scrum master and get
that added as part of a product backlog. At the end of 2-3-hour long programming session spend at least 20-30
minutes in cleaning up something you noticed as you were touching or looking at existing code.
Always discuss refactoring in your next retrospection inkling your product owner.
My suggestion is to include them as part of your sprint planning and all team members should collectively work on
that.
This is one of the meetings which happens daily with all the scrum masters and chief Product Owner can
facilitate it. It is the same as that of a daily scrum but the focus is on a team level.
Each team sends out one member to participate and answer the following questions:
These charts help to keep track of the progress of the sprint. Burn up charts indicates the amount of work completed
in the sprint and the burndown chart indicates the amount of work remaining in the sprint
The Product Owner determines the amount of remaining work and compares it to the remaining work of the
In the Burn-Down chart, the vertical axis (remaining work) shows the amount of work (which is a sum of all the
estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the
We usually add another line to present the uniform distribution of the volume of the work across the initially
estimated number of sprints. This line acts as our planned progress and will be used to compare to our actual
values.
In the above chart, we can expect the project to be completed earlier than initially planned.
In the Burn-Up chart, the vertical axis is the amount of work and is measured in units or story points, and the
Each day you can see the amount of work completed and the total amount of work. The distance between the two
lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a
Bill Wake has given us the mnemonic INVEST which help us in writing a well-formed User Story.
Splitting a story is not an easy task.
Split by user roles-Administrators interact with the system in a different way than users. It a very good
Split by capabilities offered.-Capabilities example like sorting and searching. Further sorting and
Split by user personas -Even in the same role, users interact with the system in various different ways. A
handicapped person interacts in a different way, a casual user in a different way as he needs intuitive
Split by target device- User can interact with our system not only using a standard computer but also
using mobile, ipad etc.So this is also a good way of splitting a user story.
Ideally, the team should immediately raise the issue to the Scrum Master as an impediment. Scrum Master is
responsible to take care of these kinds of problems, or impediments that stop the dev team from achieving the
Sprint Goal and facilitate a team’s optimum performance. But, it is the responsibility of the team to communicate
with the Scrum Master about what impediments are obstructing them. This communication occurs every day in the
daily Scrum and the main purpose of it is to raise any impediments and refine the plan to meet the Sprint Goal.
This typically happens when the Sprint Goal becomes obsolete. A Sprint can be cancelled before the Sprint time-
box is over. A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company
changes direction or if market or technology conditions change. The abnormal termination might also occur if the
team gets into the Sprint partway and finds that the work is going to consume too much time than expected in sprint
planning.
When multiple teams work together on the same product, should each team maintains a separate Product
Backlog?
No. One product has one Product Backlog, regardless of how many teams are working on that project. It is easy for
the Development teams to coordinate with other teams if one product backlog is followed throughout the project.
When do Development Team members become the exclusive owners of a Sprint Backlog item?
Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though each one may be done
by an individual development team member. Sprint Backlog and all of its items are collectively owned by the
Development Team. No individual team member can claim ownership over an item as this would block
Without a new vocabulary as a reminder for the change, very little change may actually happen. Also, the
organization may not understand what has changed with Scrum and the benefits of Scrum may be lost.
Scrum adoption is good, but this massive shift needs complete dedication. The organizations that are implementing
the Scrum practices every day can be successful in Scrum adoption. If Scrum is implemented with all the team
members on a daily basis can increase the collaboration and a quick product delivery. So, it is recommended to
implement only Scrum methodology without clubbing any other methodology as it can be applied to any complex
project and will meet the project deadlines within a timeline, making the customer happy!
The Development Team should not be interrupted during the Sprint. The Sprint Goal should remain intact.
These are the conditions that foster creativity, quality, and productivity. Based on this, can you say for
certain that the Sprint Backlog does not change during the Sprint?
It can change. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary
to meet the Sprint Goal. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint
Backlog emerges during the Sprint. If the work appears to be different than expected, the dev team collaborate with
the PO to negotiate the scope of the Sprint Backlog within the Sprint and adds more PBIs related to the current
Sprint if necessary.
When many Development Teams are working on a single product, what best describes the definition of
"done?"
All Development Teams must have a definition of "done" that makes their combined work potentially releasable.
Each Scrum team consists of its own ‘Definition of Done’. Definition of Done defines the acceptance criteria across
all User Stories. Scrum requires an Increment to be releasable. This is an Increment of product. Many teams
Is it mandatory that the product increment be released to production at the end of each Sprint?
No. The product increment should be usable and releasable at the end of every Sprint, but it does not have to be
released. In Scrum, it is not mandatory to release each increment without accepting the acceptance criteria. The
developed increments should have a value according to the customer’s needs. In short, you can say that it should be
usable and releasable at the end of every Sprint without releasing to the production.
The CEO asks the Development Team to add a "very important" item to a Sprint that is in progress. What
should the Development Team do?
Inform the Product Owner so he/she can work with the CEO. The items selected for a Sprint have been selected as
most valuable with the Product Owner. The items serve the Sprint's goal. No changes should be made that endanger
the Sprint Goal. No one external to the Scrum Team can force changes on the Development Team (Sprint Backlog)
During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who
should be present to review and adjust the Sprint work selected?
The Product Owner and the Development Team. During the Sprint, the scope may be clarified and renegotiated
between the Product Owner and Development Team as more is learned. As issues emerge, changes can be made to
the sprint backlog to accomplish the Sprint Goal. The Development Team will then re-negotiate with the Product
Owner regarding the Sprint Backlog. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not.
The Product Owner's authority to change and update the Product Backlog is typically unlimited. Is there
ever any exception?
No. The entire organization must always respect a Product Owner's decisions. For the Product Owner to succeed,
the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work
from a different set of requirements, and the Development Team isn't allowed to act on what anyone else says. The
PO can remove the product backlog items if he/she feels that is not a high priority one. Anyone can add an item to
the product backlog. But, it is the PO who decides what happens to the PBI.
it. Secondly, it creates transparency regarding progress within the Scrum Team. All Scrum Team members must
have a shared understanding of what it means for work to complete, to ensure transparency. This is the definition
of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment. The
Increment reviewed at the Sprint Review must be usable, so a Product Owner may choose to immediately release it.
The Development Team finds out during the Sprint that they aren't likely to build everything they
forecasted. What would you expect the Product Owner to do?
Re-work the selected Product Backlog items with the Development Team to meet the Sprint Goal. During the
Sprint scope may be clarified and re-negotiated between the Product Owner and Development Team as more is
learned. The development team looks to the product owner for product backlog, for alignment and direction on the
delivery of value through the sprint goal achievement through the backlog implementation. The backlog can be
changed to achieve the Sprint goal, but PO is responsible for value delivered through the implementation of
It is usually seen that learning turns into 'validated learning' when assumptions and goals can be assessed
through results. What is a key way for a Product Owner to apply validated learning?
Release an Increment to the market to learn about the business assumptions built into the product. The Product
Owner manages Product Backlog against the assumption that value will be generated. This assumption remains
invalidated when not checked against users and market. The Product Owner drives iterative development from an
exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.
No. In Scrum, Product Owner takes care of the Product Value in order to generate, deliver, and maintain a
successful product. Value is likely to vary across the products and organizations. The value of the product depends
created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight
hours for a one-month Sprint. What can be achieved in this time-box may be influenced by additional practices that
Is Sprint Review the only time during which stakeholder’s feedback is taken into account?
No. A Product Owner engages actively and regularly with the Stakeholders. However, to limit the disturbance to
the development progress and keep a focus of the Development team high, the key Stakeholders are allowed to take
part only in the Sprint Review meeting. However, any Scrum team member can interact with them at any time.
How does an organization know that a product built through Scrum is successful?
By releasing often, and updating key performance indicators (KPIs) on value after every release and feeding this
information back into work on the Product Backlog. Scrum Teams deliver products iteratively and incrementally,
maximizing opportunities for feedback. If a product isn't released, the opportunity to capture user and market
feedback is lost. By releasing every increment and updating the Key Performance Indicators (KPIs) on value after
every release can help to know the product built through Scrum is successful.
What variables should a Product Owner consider when ordering the Product Backlog?
Whatever is the most appropriate for the Product Owner to achieve the product's goals and to optimize the value
received. The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and
missions, thereby optimizing the value of the work the Development Team performs. How this is done, and what
In order to make investment decisions, the Product Owner is likely to look at the Total Cost of Ownership
(TCO) of the product being built. What costs will a Product Owner take into account?
The owner of a product is not only accountable for the development and release of a product, but also the cost of
maintaining and operating the product. If a person 'owns' the product, he/she can be expected to be responsible for
How important is it for a Product Owner to order Product Backlog items by value points?
It is a good practice, keeping in mind that market reception is the best measure of value. Indications of value on
Product Backlog are useful but are only a prediction until validated against users and market.
Should each Sprint Backlog item be owned by a member of the Development Team?
No. Single members might handle most or all of the work of a particular Sprint Backlog item, but responsibility
remains for the whole team. When each member of the Development team owns the Sprint Backlog items, the team
will derail from the core-value of Agile which is nothing but the ‘Collaboration’.
A representative of the customer has asked the Development Team to add a very important item to an
ongoing Sprint. What should they do?
Refer the representative to the Product Owner to discuss it. If the customer is asking for adding an item to an
ongoing Sprint, adding it in collaboration with the Product Owner is the best-suited way to add any new item to the
Sprint. Because adding a new item to the product backlog without asking the product owner may result in removing
a transparency and undermining trust with the Product Owner.
Timeboxing is the process of allotting a fixed and maximum unit of time for an activity. That allotted unit of time is
a timebox. The goal of timeboxing is to define and limit the amount of time dedicated to an activity. The time-box
set for the Sprints should not be longer than one month and should be selected considering different factors such as
Because adding a new item to the product backlog without asking the product owner may result in removing a
A Development Team with 5 members has been using 15 minute Daily Scrums. Three new members have
joined the team. How long should the Daily Scrum meetings be after that?
15 minutes. The purpose of the Daily Scrum meeting is to carry out communication between the team members.
The Scrum meeting is timeboxed to 15 minutes irrespective of the team-size and is held at the same time and place
each day to reduce complexity. Also, it is usually held in the morning time when maximum team members gather to
Product Owner.The Sprint can be called off before ending up the Sprint time-box. Only the Product Owner has the
authority to cancel a Sprint. This happens when the Product Owner realizes that it makes no sense to finish the
Sprint, as defined in Sprint Backlog. The PO may cancel the sprint under the influence of any Stakeholder, the
For projects which have multiple teams, how many product backlog(s) and product owner(s) should be
there?
There should be one Product Backlog and one Product Owner. Many Scrum teams, each with a Scrum Master can
pull work items from a single product backlog and the presence of the product owners depend on the number of
product backlogs. A certain project should have only one Product Backlog and one Product Backlog should only
have one Product Owner otherwise, it would be difficult to deliver the product.
To deliver a single product, three Development teams are formed. How many Product Owners are needed?
One. Multiple Scrum teams, each with a Scrum Master can drag their work items from a single product backlog and
the presence of the product owners depend on the number of product backlogs. A certain project should have only
one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it would be difficult
A Scrum Team crafts the following Sprint Goal: “All the Sprint code should have passed 100% automated
unit tests”- Is it an appropriate goal?
It is not an appropriate goal since Sprint Goal should be about expected business value.
An important executive wants the Development Team to take a highly critical feature in the current Sprint.
What should be the Development Team’s course of action?
The development team should ask the executive to work with the Product Owner. The product owner is the voice of
the executives in the process of communicative discovery. How the feature is developed is up to the PO and the
Scrum Team, and depends on the nature of the product under deployment and the availability of the stakeholders.
The product owner represents the needs and desires of the executive to the development team and prioritizes their
Since the Scrum team is self-organizing, do you think it can create an additional role within the Scrum?
No. The benefit of forming self-organizing teams is not that the team identifies some additional role within the
scrum for its work that a manager has missed. Instead, it is that by enabling the team to self-organize, it is
motivated to completely own the problem of performing the work at its best. In short, a self-organizing team is a
group of motivated individuals who have the authority and ability to take decisions and adjusting to changing
A customer wants to communicate something very relevant and important about the product to the
Development Team. Who should he/she talk to?
The product owner only. A customer shouldn’t spend time detailing the product issues to the development team,
this is the job of a product owner. The product owner is responsible for the project success and is finally responding
to the customers, team and to the company. He/she is the voice of the customer to the development team and
ensures that all channels of communication are open and that project has ample amount of support needed to
succeed.
In a retrospective, a Scrum team decides to revise the Sprint length. Does the Product Owner need to agree
on the new Sprint length?
Yes, the length of the sprint can be changed but it should be fixed before starting the sprint. The product owner
needs to ensure that the sprint is short enough to limit business risk and also short enough so that the team can
synchronize their development work with other business events. Finalized Sprint length cannot be longer than 4
weeks (1 month).
The Scrum Team gathers for Sprint Planning meeting. The Product Owner has some stories, but the team
finds that stories do not provide enough information to make a forecast. What according to you is the
immediate next thing to do?
The Development Team should it transparent that they cannot make a forecast with insufficient information, and
negotiate with Product Owner on refining the stories to a Ready state. In scrum, each and every iteration starts with
a sprint planning meeting. During this meeting, the PO and the team discuss which stories a team will handle that
sprint. The Product Owner needs to help clarify the selected Product Backlog Items. Scrum Master can also coach
the Product Owner on how to accomplish this viz. by having regular Backlog Refinement sessions. Later, the team
Given the complex product and its relevance to multiple departments, a Scrum Team expects that they need
to invite many stakeholders for Sprint Review. It estimates that the review will take more than 4 hours. Can
it increase the Sprint review duration?
No. After developing a product increment at the end of each sprint, a Sprint Review meeting is held. The Sprint
Review meeting provides a platform to the team members to show what they accomplished during the sprint.
Scrum events are time-boxed to eliminate waste and reduce risks. The team needs to address the root causes and
A Development Team maintains a Sprint burn-down to track estimated work remaining. In the middle of
the Sprint, the burndown graph shows an upward Spike. What does it indicate?
This indicates that the development team added new work. The line indicating effort remaining in the burndown
graph varies from team to team and day to day. If more work items (user stories and issues) are added after the
sprint started then this shows an upward spike. The spike indicates added work and the Product Owner cannot add
After Sprint Planning, the Product Backlog Items selected into the Sprint backlog are frozen and cannot be
modified. In that case, is the only way to modify it is to have the Product Owner cancel the Sprint?
No. The Sprint Goal gives some flexibility to the Development Team. If the work turns out to be different than
expected, the Development Team collaborates with the Product Owner to negotiate the scope of the Sprint Backlog
within the Sprint. In that case, the development team discusses with the PO and reaches the conclusion.
Where did Scrum come from?
The development of the Scrum framework is not linear; different people did independent studies and experiments
and gradually the ideas and concepts coalesced into what we know today as Scrum.
Probably the first publication that compared product development to the game of rugby, moving the scrum down
the field, was the white paper “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro
In this whitepaper, the authors researched the product development methods of prominent and successful
Built-in instability
“Multilearning”
Subtle control
They called such processes ‘Holistic Methods’ as opposed to the waterfall ‘sequential’ processes.
Some sources attribute the ‘invention’ of Scrum to Jeff Sutherland, John Scumniotales and Jeff McKenna in 1993
Independently, Ken Schwaber, as a software product development manager in the 1980s and early 1990s,
recognised patterns of failure in many product development initiatives that used ‘waterfall’ approaches.
Ken tells the story that he approached a process engineering company, described the software development
environment and ‘waterfall’ process; he was told that a ‘defined process’ such as ‘waterfall’ was very unlikely to
succeed consistently in a software development environment; what is needed is an ‘empirical process’ that allows
You would need to ask Jeff or Ken how these 2 first came together to ‘compare notes’ but they collaborated to
Coplien and Mike Beedle.
Ken Schwaber and Mike Beedle published the first Scrum book, ‘Agile Software Development with Scrum’, in
2001.
How does the Inspect and Adapt process work during a Sprint?
The Inspect and Adapt process is important throughout the Sprint but especially during the ceremonies:
o The Risk Log to determine if any significant mitigation actions are required for high risks in the
Daily Scrum – During the Daily Scrum it is important to Inspect the progress toward the Sprint Goal and
if there are any concerns about the progress, consideration must be given to Adapting the current priorities,
o The increment produced to discover if any Adaptations (changes) are required and the priority of
those Adaptations
o The Product Backlog to determine if it needs to be Adapted in the light of any new PBI required,
o The Release Plan to determine whether it needs to be Adapted considering the experience gained
Scrum Retrospective – During the Scrum Retrospective it is important that the team Inspect:
The results of these Inspections should lead the team in considering the Adaption of the process that they followed
Why are the Scrum Pillars of Transparency, Inspection and Adaptation so important?
The
empirical process control theory asserts that knowledge comes from experience and making decisions based on
what is known ie at defined points within an overall control process, teams must inspect what has happened and,
The Scrum framework is founded on empirical process control theory so the included ‘Transparency, Inspect and
Transparency
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of
the artifacts. If the transparency of artifacts is incomplete, these decisions can be flawed, the value may diminish
Inspection
Scrum users must frequently inspect Scrum artefacts and progress toward a Sprint Goal to detect undesirable
variances. Their inspection should not be so frequent that inspection gets in the way of the work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable limits and that the
resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment
Transparency and Inspection are important in the Daily Scrums and Sprint Reviews. Although Adaptation is
mainly considered during the Sprint Retrospective, it should be considered at any time during the Sprint if the
When problem-solving and idea creation is needed, for example when constructing the Product Backlog from a
product Vision, Objectives and Expected Benefits, there are 2 strategies that are usually used, divergent and
convergent thinking.
Divergent Thinking
The “divergent thinking” strategy used to solve problems is the proposal of multiple possible solutions then
In a ‘problem solving’ workshop, the participants are asked for any ideas individually; writing on ‘sticky notes’ is a
good idea. The results are analyzed to see if there is any overlap and the participants agree on a single list of
potential solutions.
During the analysis of the potential solutions unexpected combinations may be made, information may be changed
into unanticipated forms, connections among remote associates may be identified. In divergent thinking, a single
question returns multiple answers and though the answers vary considerably depending on the workshop
participants, all answers are of equal value; each proposed solution may not have existed before and therefore may
Curiosity – The personality characteristic of asking questions, learning to get more knowledge/information
Elaboration – The skill of adding to, building from or enhancing a product or an idea
Flexibility – The capability of creating different perceptions or categories from which a range of different
Fluency – The skill of producing many ideas so as to have an increase in the number of potential solutions
Originality – The skill of coming up with fresh, unusual, unique, extremely different or completely new
products or ideas
Divergent thinking has been detected in people with personality characteristics such as curiosity, nonconformity,
An extreme example of divergent thinking was when Twitter developed an online service that did not have any
obvious practical application. The company deployed a basic application to find out how people used it and, based
on the findings, refined the application. Though launching something and finding out what the market for it is only
after the launch doesn’t have to be a bullet-proof strategy (in most cases it is not), this worked for Twitter.
Convergent Thinking
Once the divergent thing ‘phase’ of the problem-solving session has been ‘completed’, the workshop participants
use convergent thinking to bring together the different ideas to determine a single best solution.
The term “convergent thinking” was ‘created by Joy Paul Guilford. He came up with the term as an opposite term
to “divergent thinking”.
Convergent thinking needs speed, logic, and accuracy and relies on identifying the known, reapplying techniques
A vital part of convergent thinking is that it produces one best answer; you either have a right answer or a wrong
one.
An example of where convergent thinking would be used is when the problem is:
This would require listing all the criteria that the ‘buying’ company need from an outsourcing company and
examining each to see which has the best ‘off-the-shelf’ fit or maybe which is open to negotiate to meet all the
required criteria.
Summary
Divergent thinking is used to go from one stated problem to many potential solutions.
Convergent thinking is used to form multiple potential solutions to the correct one.
How can a group of people reach a final decision during Scrum project implementation?
Making decisions in a group has its advantages and disadvantages; the main advantage is that there will be more
information and data available by which to make the decision; the main disadvantage is that it can take a significant
amount of time.
Let us consider first a jury for a trial. The decision that they must make is ‘black and white’ or binary; is
A jury session usually starts with a vote amongst the jurors, guilty or not guilty. There follows a
discussion between people on either side why they have the opinion that they have. By this means,
each juror hears opinions about pieces of evidence that they may have forgotten or dismissed and the
After a set time, another vote is taken to see in which direction the overall opinion is ‘going’.
It depends on whether a majority or unanimous verdict is required; if majority, once the requisite number
of people all vote the same way, the decision is made; if unanimous, there is a danger that the longer the
discussions go on, those in the minority will vote with the rest just to ‘get it over with’.
There is another decision that a jury can make, they cannot agree to the set majority or unanimous
But not all decisions are ‘black and white’, most represent a range of options that must be chosen from.
The following are the major recognized ways in which groups of people can come to a decision:
Consensus decision-making
At the start of the decision making ‘workshop’, some participants will have their own opinion of
which way the decision should go usually based on their own or their ‘departments’ best interest.
However, the aim of the consensus process is to reach a decision in the best interest of the
whole.
The first thing a facilitator must do is to establish the agreed boundaries of the possible decision
spectrum; for an extreme example, if the decision is to be made about new products in a
consumer product manufacturing organization, you wouldn’t expect the boundaries of the
spectrum to include ‘Make a spacecraft’. However, the facilitator must not allow the group to
others listen and ask direct questions to further understand the reasons from their own frame of
reference.
In this way, the group opinion gravitates in one direction. Eventually, those in the minority,
unless vehemently opposed to the majority, agree to ‘let’s see how it goes and review later’.
Voting-based methods
Voting of some form will always form part of any decision-making process. In all discussion-
based decision-making, votes are solicited at regular intervals to get a ‘snapshot’ of the group’s
Let us see all the voting processes in detail that may be used:
Range voting – Each participant gives each option a score based on an agreed scale and the
This method has been shown to produce the highest participant satisfaction with the result
the bar for action is lower than with unanimity and a group of "losers" is implicit to this rule.
Majority voting is not considered suitable for business group decision making unless a great deal
‘First past the post’ – With ‘first past the post’, each participant votes for one option; the option
the participants; it is unlikely that those in the majority will actively support the decision.
Delphi method
This method is a structured communication technique for groups, originally developed for collaborative
forecasting. It involves ‘experts’ answering a series of questionnaires and after each questionnaire is
completed, a facilitator presents anonymized results and the reasons for those results. The idea is that
each expert modifies their opinion based on the reasons and it is expected that the range of opinions
You can possibly see that Consensus decision making is a less structured version of Delphi; all
workshop participants are experts in their own field, but their opinions are not anonymized.
Dotmocracy
Using this method, participants are asked to place ‘sticky dots’ or use maker pens to indicate for which
option they vote for. The may be given one vote or a range, identified by colors, such as ‘I want this one’
(green), ‘I would be OK with this one’ (orange) and ‘I do not want this one’ (red).
‘First past the post’ – Like the description of this above, the decision to be adopted would not be
the option that the majority voted for but also the option that the least number of participants that
consideration and further discussion can take place on a reduced set of options with further
The disadvantage of this way is that innovative options may be dismissed too early.
with many facilitation tools, facilitative listening is perhaps most useful when there is a chance that conflict may
arise. Facilitative listening is sometimes known as ‘active listening’ and is ultimately about making sure
Paraphrasing
It may be that the listener does not totally understand the statements being made by someone:
The listener could ask the speaker to restate their argument using different words
The listener could state their understanding of the speaker’s words but in the listeners’
vocabulary
Part of your responsibility as a facilitator is to be aware of the listeners ‘body language’ and if you believe
that one or more are not fully understanding what is being said, you could ask:
Mirroring
Workshops are set up for participants to express themselves but more than just space for expression is
needed. If a participant speaks without a sense of being heard, they are likely to either ramp up their
expression or else shut down neither of which is desirable for collaborative decision making. Mirroring
requires that the speaker can feel that they have been listened to.
After several people have spoken, a facilitator gives a summary of what has been said so far
The facilitator can offer a direct paraphrasing back to someone who's just spoken, offering a
The facilitator or a workshop scribe can write key points onto a shared display that everyone
After a general discussion, a synthesized statement may be drafted by one or a few people
Mirroring may happen in the moment of a session or in after/between sessions as part of a longer,
iterative process.
The effectiveness of Mirroring may be enhanced by checking with those reflected to see if the Mirroring
was accurate.
Not all the Mirroring needs to be done by one central facilitator. A facilitator can also invite others to
Mirroring summarizes the state of current knowledge. Once what is now known is acknowledged, that
naturally opens space for new ideas and creativity to emerge, whether for one participant in a meeting or
Making space
they need a space where they will be comfortable and without distractions.
1. Has no external distractions; noise from roadworks, air-conditioning rattling, next to a noisy office
etc
2. Is it a comfortable temperature
3. Has sufficient refreshment facilities available
4. Has enough space to accommodate the number of participants and ‘break-out’ sessions
Stacking
This technique to aid facilitative listening is called ‘Taking Stack’ and its purpose is to facilitate discussion
and decision making in which all participants have equal say in a conversation. Otherwise, in a
structure-less setting, an individual or a small group of people could easily dominate and shut out other
participants.
For this method, one group participant needs to fill the role of the Stack Keeper whose responsibility is to
“The Stack” is the order of participants who are speaking. If a participant raises their hand to say
something, the Stack Keeper puts them on “Stack”; their name is put at the bottom of stack list. When
the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and
Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack
Keeper must constantly be paying attention and looking around the room to see who wants to speak.
There are other hand gestures to indicate a request for more immediate contribution when someone else
is speaking:
Direct Response
If a participant has a “direct response” to something that another group member said, they should make
the hand motion shown in the picture (index fingers out, thumbs up, moving hands up and down in
opposite directions). A “direct response” is only a correction to something that was incorrectly stated by
another participant, an answer to a question that another participant had, or that is so important that it
The Stack Keeper allows this participant to state their response before the conversation goes on.
Correct Usage: “You asked who volunteered to take over your shift? That was me.” OR “Actually, the
Clarifying Question
Any participant may make the hand gesture in the picture to indicate that they want to ask a “clarifying
question.”
The Stack Keeper allows them to ask their question before stack goes on.
Incorrect Usage: “How can you say that when you disagreed with Jeremy’s point?”
Point of Process
If a participant feels that the group discussion is not following the correct procedure or a discussion has
gotten off topic, they may make this hand gesture and say out loud “Point of Process.”
The Stack Keeper allows them to speak before the next person at the top of the stack. They must then
say how they think the discussion has gotten off topic or is not following procedure.
Example 1: “I’m not sure why we’re talking about shifts when the agenda says we’re supposed to
on to anything else.”
What is the ‘Coaching Stance’ and how does it impact any coaching situation?
The coaching stance is what the Agile Coaching Institute (ACI) refers to as “the heart” of their Agile Coach
Competency Framework. The coaching stance is supposed to be the place you start from and return to.
maintaining neutrality – do not judge peoples’ attitudes or actions; question them about the whys and
serving the client’s agenda – do not approach a coaching situation with a set of pre-defined directions that
reducing client dependence – introduce thinking and decision techniques that, once used by the client,
not colluding – do not collude with the client to introduce attitudes and practices that would be detrimental
to the organisation even if they believe that that is what they want
Which ‘Coaching Techniques’ can I use to help the team be more self-organising?
Self-organising teams is one of the keys to Agile success but experienced developers who are used to working in a
‘command and control’ environment may find it difficult to adopt this Agile practice; they are used to being told
what to do next; instead of asking the PM how to do something, he/she should consult their peers on the
development team; if no one knows, that is an impediment and the Team should discuss how to resolve the issue.
The Scrum Master, as the Risks and Issues Manager, can help the team decide how to resolve the problem but
The main coaching techniques that a Scrum Master can use to help the team become more self-organising are
Powerful Questions – are used by a coach to extract more details about a problem or situation; making the
inquirers articulate their answer often organises their thoughts so that they start to answer their own
questions.
Powerful Questions are open questions ie they cannot have a yes or no answer; they usually start with ‘who’, ‘why’,
‘what’, ‘when’, ‘how’ or ‘where’; they may also start with statements such as ‘Tell me about …’.
Reflecting a statement back to an individual can help prompt further exploration; for example, “You said you were
For more information about Powerful Questions, see Coaching with NLP.
Autonomy, Mastery and Purpose – One way for a Scrum Master to help with self-organisation is to look
at the Team members’ motivation. People who rely on outside influences for their motivation, so-called
extrinsic motivation, are far less effective than those that are self-motivating, so-called intrinsic motivation.
To foster the intrinsic motivation, we need to examine the following aspects of individuals and the Team:
Autonomy – We all have an inner-drive to satisfy our psychological needs; if what we are told what to do
Giving individuals and teams more control of what to do, when and how to do it, motivates them more.
Also, if individual Team members identify with their team (their tribe) the team becomes more autonomous and
self-directing.
Mastery – Do not expect individuals or Teams to master Scrum straight out of the training course.
Mastery comes from small steps from what they know now to the goal of Mastery; you possibly know of
the problems associated with ‘big-bang’ implementations; the same is true with ‘big-bang’ Mastery.
As a Scrum Master you should discover what the Team members know now and ask them to have a go at
something small but significant in Scrum and give them the space and time to experiment on their own to work out
how to do it.
Most people want to do better; by helping individuals and Teams toward Mastery leads to greater Team self-
organisation.
Purpose – People and Teams who understand and buy-in to why they are doing their work are much more
motivated than those who come to work just to pay the bills and do not care about the work.
Whenever possible, involve the Team in the early stages of product development; let them hear the discussions
about forming the Product Vision and Objectives; let them have an input to the Product Backlog ordering.
For more about Autonomy, Mastery and Purpose see Drive by David Pink and Intrinsic Motivation by Richard
Active Listening – To help you gain trust with individuals and Teams, as a Scrum Master you need to use
Active Listening techniques to show that you care, understand and are prepared to help them. The
following are the techniques that some coaches use; there are others:
Pay Attention
Give the speaker your undivided attention and show that you are hearing the message; your non-verbal
communication, body language, can help the speaker feel comfortable.
Do not mentally prepare a response to one thing the speaker has said; you will not be listening to what
Use your own body language and gestures to show that you are engaged.
Nod occasionally
Smile
Make your posture open and interested
Encourage the speaker to continue with small verbal comments like yes and OK
Provide Feedback
Your own assumptions, judgments, and beliefs can ‘distort’ what you hear. As a listener, your role is to understand
what is being said; this may that you have to ask questions to clarify what is being said.
Paraphrase what has been said; for example, "What I'm hearing is... " or "Sounds like you are saying... "
Ask questions to clarify certain points; for example, "What do you mean when you say... " or "Is this what
you mean?"
Defer Judgement
Interrupting a speaker is a waste of time; it is frustrating for the speaker and reduces understanding of the
message.
Ask the speaker if he/she has finished a point and if it is OK to ask a question at this time Respond
Appropriately
Do not ‘attack’ the speaker; show respect and understanding of the speaker’s position. You are gaining
information and perspective.
Which ‘Coaching Techniques’ can I use to help the team be more self-organising?
56.
What are the challenges facing self-organising teams and how can I help reduce the impact of these
challenges?
There are many challenges facing self-organising teams which can be grouped into the following categories:
Organisational inertia. In organisations that have been around for some time, the way that things are done have
become habits; many supervisor and management personnel are reluctant to change from fear of their job changing
Individual Team members’ inertia. Individual Team members may have fears about:
A Scrum Master must be aware of these potential challenges to self-organisation, look for signs of them and help
Below are 3 typical challenges faced by teams and the possible help that a Scrum Master can give:
Bad Forecast: In the early stages of an Agile transformation, the Teams may be asked to estimate using
Story Points, relative estimating, instead of the conventional task estimates that they have been used to.
This technique requires practice to become proficient and early attempts may result in the forecast at Sprint
Planning for Product Backlog Items (PBI) to be attempted being significantly in error, generally, Teams
tend to under-estimate. This may demotivate some Team members and make them question the use of the
new technique.
Solution: During the early Sprints, at the daily Scrums, the Team will realise that their progress toward the
agreed Sprint Goal is slower than they would like. As a Scrum Master, you should ask the Team if there is
anything they can do to improve progress; some changes could improve progress.
However, the time to address the underlying problem to do with estimating is during the Sprint Retrospective when
the estimates for each Sprint Plan PBI should be compared to ‘actuals’ to see if there was any common reason for
the estimates being inaccurate or if there were one or two ‘one-off’ estimating mistakes.
If there was a common or systemic reason for inadequate estimates, the Team must re-estimate the Product Backlog
in the light of the new evidence; if the errors were due to ‘one-off’ inaccuracies, the Team should re-estimate
to learn from their experience and apply that learning going forward.
Technical Debt: We build products incrementally; ‘only do today what you need to do today’. It is
probable in later increments that some code that worked for a previous increment no longer works for the
current increment so the code is changed. Over time a single method in the code may have had several
‘patches’ applied to it so that becomes difficult to read and restructure when further ‘patches are needed;
this may cause de-motivation in some Team Members and even cause arguments between them about the
The programmers aim is for ‘clean’ and simple code but the temptation is to produce something that works now
without considering future maintenance needs. The fact that the resulting code may not be ‘clean’ and simple is
Solution: Resolving Technical Debt costs time and money; the longer you leave the resolution, the more
There are 3 suggested solutions that a Scrum Master can encourage the Team to adopt to address potential
Definition of Done (DoD): Ask the Team to add an item to the DoD to ensure all new or changed code is
peer reviewed to ensure that the structure is ‘clean’ and any potentially reusable code fragments are
Do not let the Team wait until the end of the Sprint to do the code reviews, have them do it once the programmer
believes that he/she has finished. In this way, there is the shortest time between ‘finished’ and any refactoring that
may be needed.
Pair-Programming: The idea of two programmers working side-by-side to develop one function may
seem counter-intuitive; it would cost twice as much to produce the code. However, in the medium to long-
term, Technical Debt may be reduced or even eliminated when one programmer is looking on and offering
With TDD, no line of production code is written before a test has been written to test it, the test is run and is
expected to fail. Only enough production code is written to pass the test. See Test-Driven Development.
Practicing TDD does require an Integrated Development Environment that supports it and to be successful, all
Initially, some programmers may be reluctant to use it because of the perceived extra work; however, when they
see that the maintenance effort is reduced by more than the extra initial work, they come to accept the practice.
Team Member Leaves: Each Team member has a list of responsibilities and capabilities including their own
The Scrum Master should keep a list of all these responsibilities and capabilities so that when a Team member
leaves the Team for some reason, the remaining members can distribute the leavers responsibilities and capabilities
amongst themselves.
If it is not possible for any of the remaining Team members to take on any required responsibility or a required
capability is not available, the Scrum Master must raise this as an issue with the Product Owner and management; a
Team member training may be the resolution to the issue or an additional Team member may be introduced to the
Team. In the latter case, the Scrum Master should monitor how the ‘new’ Team are managing their self-
organisation.
How can a self-organising team approach challenges that they discover during a Retrospective?
Even good self-organising teams can face challenges with Retrospectives in how they are run and addressing issues
that they discover.
The following are some of the most commonly experienced challenges with their suggested solutions:
Apathy: After a while, some Team members may consider that the Retrospective is a waste of time:
They have already discussed problems that are out of their control to resolve
Solutions:
The Team must devise a plan to attempt to resolve ‘external’ problems probably involving the Scrum Master as the
innovatively change some parts and review the changes at the next Retrospective
Boring: If all Retrospectives follow the same ‘sit around a table and discuss’ format, they will quickly
become boring.
Solution: The Retrospective facilitator should change the format of the Retrospectives by using ‘games’ to elicit
required information from the group; see Fun Retrospectives and Agile Retrospectives Ideas: Games For Your Next
Retrospective for more ideas than a Retrospective facilitator could possibly use
All Talk, No Action: During early transformation Retrospectives, the Team are likely to come up with many
impediments; the list may seem daunting and the thought of discussing them all is de-motivating. Also, although
the impediments may be discussed and understood by all, there is no plan to resolve any of them
Solution:
Timebox the discovery of impediments. The Team members will, hopefully, only come up with their most
important impediments
Treat the Impediments or Blocks List like a Product Backlog Before discussing any impediment, get the Team to
order them in terms of Team importance Discuss only the top 2 or 3 impediments and produce plans to try to
resolve them Every 2 or 3 days during the next Sprint, get the Team to state how the plans are going
The first item for the next Retrospective should be to discuss the result of the plans; removing the impediment if it
has been resolved or putting it back onto the Impediments List for consideration with the rest of the un-resolved and
un-discussed impediment
Generally:
Working groups consist of individuals with specialist skills who take their direction of from a supervisor or
manager to produce an output but who do not necessarily interact with each other; ‘traditional’ software
development ‘teams’ follow this model; each team member is a specialist whose work is controlled by the
Project Manager.
Teams are comprised of people with specialist skills but interact with each other to produce an output;
individuals may work outside of their specialist skills in to produce a ‘team output’
The following table compares how attributes differ between working groups and teams:
Come together to share information and perspectives Frequently come together for discussion, decision making,
problem solving, and planning
Define individual roles, responsibilities, and tasks Define individual roles, responsibilities, and tasks to help team do
its work; often share and rotate them
Concern with one’s own outcome and challenges Concern with outcomes of everyone and challenges the team faces
Purpose, goals, approach to work shaped by manager Purpose, goals, approach to work shaped by team leader with
team members
There are many lists of the key attributes of effective Agile Teams produced; the following list distils and collates
Effective Agile Teams set their own Working Agreement, Ground Rules, whereby the members know and buy-into
the Team working practices into which are usually elements to do with all the following attributes.
Working Together/Collaboration
In a successful agile team, the team members work together on features; UI designers, developers and testers work
All Team members are aware of their own and colleagues’ strengths and weaknesses so he/she knows who to go to
for improvement advice for themselves and who else he/she can help to improve.
As the successful agile team collaborates to finish features, they avoid the problem of having many features started
Obtaining feedback at regular, short intervals is a major contributor to the success of an Agile team; they use 1 to 3-
week Sprints so they can produce potentially shippable increments of a product to obtain feedback form the wider
stakeholder community. During the Sprints, if it is not possible to work with end-users directly, successful teams
will seek feedback at every stage of the development of each Product Backlog Item (PBI).
Being Adaptable
As in all product development, conditions are not always favourable in an Agile environment:
The Agile team may not have acceptance criteria for every PBI
However, the Team must get the work done; Agile team members must be adaptable to any kind of situation (be it
Agile team members must be willing to work outside their specialisations. This does not mean that they are
expected to work in areas that they know nothing about; they can help other Team members under their
supervision; the simplest form of this is for anybody to run test scripts if they are becoming a bottleneck.
Intra-Team Communication
Good intra-Team communications is one of the major characteristics of a successful Agile team; Team members:
must have the ability to ask for help promptly when they need it
Being Committed
Successful Agile teams members are fully ‘bought-in’ the Product Vision and Objectives and are fully committed
to achieving the best value for the business within time and cost constraints.
They try to find ways to share their knowledge, learn various new things and enhance their own skills.
Also, all Team members must be able to see where Team members’ workloads stand at all times; if someone is
overloaded, members must be willing to help the over-burdened person so as to smooth workflow across the team;
There are several ways to help a Team improve its performance but they can be categorised as follows:
Ensuring the Team has common goals and purpose: The performance of a Team that is ‘pulling in different
directions’ will never be optimal; all Team members must know the product development and objectives and fully
Ensuring the Team understands and embraces Shared Accountability: We all understand self-accountability; you
do something wrong and you pay the price.
Team Accountability or Shared Accountability is taking responsibility for others ie Team members must be aware
of the work that others are doing and be prepared to challenge their work for the good of the Team
Having a Working Agreement: A Team Working Agreement states the ‘rules’ that the Team will follow to produce
a valuable product; is something that the Team members discuss and agree; nobody ‘issues’ a Team Working
The Agreement can contain anything that the Team would feel useful to enhance collaboration ie:
Ensuring Psychological Safety: Psychological safety is the belief that the individuals within the Team are
safe for interpersonal risk taking ie a Team member must be able to be themselves and speak their mind
What is an ‘homogenous team’ and what are the pitfalls of having one?
A homogenous team is one where the members are all similar in background, gender, age and culture; we are not
Homogenous teams have been shown to suffer from the following drawbacks:
Stifling of creativity – homogeneous team members have a similar world view and so find it difficult to
Communication – Although homogeneous team members may think they understand what is meant by a
colleague’s jargon, they may have misinterpreted which may lead to mistakes; in Teams with members
from diverse backgrounds it is more likely that such jargon will be challenged and a greater understanding
Minorities – People not of the same background as the homogeneous Team members may have feelings of
All multi-staged models for team formation recognise different stages that a group of people go through from the
There are several published models from those that involve rigorous mathematical steps to analyse team needs and
Reliant on leader
Storming
Strong emotional responses to team and task
Norming
Open exchange of information, emotional support, team cohesions
Performing
Team becomes a “working organization”
Outperforming
Team exceeds the performance norms
Adjourning
Change is embedded into the organization
Item (PBI) before it can be considered ‘Done’ and is fit for review by the wider stakeholder community and
potentially released to the live environment; the DoD is a key artefact for Product Development quality control.
The DoD is assembled and agreed by the Product Owner (PO) and the Development Team members.
There is a possibility that the Team develop a minimalist DoD and submit it to the PO for approval; some PO will
In such situations, as a Scrum Master, you should remind the PO that he/she is solely responsible for the value to be
accrued from the Product Development and that he/she needs to understand each DoD element in case any have
been forgotten or any are unnecessary; the best way to achieve this is for you to facilitate a DoD workshop with the
Another problem with minimalist DoD is that they assume that small but significant steps in the development
process will be done because ‘they are obvious’; they may be obvious in the ‘cold light of day’ but not so obvious
in the ‘heat of development’; as a Scrum Master, you should encourage the rest of the Scrum Team to include more
detail in the DoD than seems necessary; items can always be taken out if they are felt to be redundant.
DoD Examples
The DoD for software development may include items such as:
The DoD for a PBI is usually peer-reviewed by another Team member that has not had significant input to the PBI
development.
Given that Scrum is not just for software development, a DoD for a non-software product development, such as
running an event, may look something like this for the PBI of ‘As the Invitations Coordinator, I need to send
The list of invitees has been collated from the {xyz} customer list
The list of invitees has been approved by the event Project Manager
The form of the invitation has been designed by the Marketing Dept
The form of the invitation has been approved by the Marketing Director
Once all the DoD items have passed their checks, the Invitations Coordinator is authorised to send out the
invitations.
The ‘Agile Technical Practices’ or ‘Agile Programming Practices’ all come from work carried out or developed
from other ideas by eXtreme Programming practitioners; They are not part of Scrum or any other Agile framework
but have been adopted by many, if not most, Agile programmers as a ‘toolkit’ of ‘best practice’ for producing
minimal, ‘clean’ and maintainable code. The list of practices, with explanations, is as follows:
A common "war-room" style work area – Where Team members are co-located, they should occupy an
There will be many artefacts that are best displayed on a wall and it is best to keep them in one place.Also, the
Team members can obtain ‘osmotic communication’ just by being in the same area as others having conversations.
Sharing the codebase between all or most programmers – Individual programmers do not ‘own’ their
Sprint but may have to be modified for other functionality in a later Sprint), other programmers need access to all
the code in order to update it when necessary; if they do not have access, they may write redundant code.
A single coding standard to which all programmers adhere – Just as sharing the codebase is an
important practice, having a common coding standard reduces the time that a programmer needs to
Pair-programming – The simplest practice to implement, it requires that no line of code, production or
test, is written without 2 people being involved; one typing at the keyboard, the other reviewing what is
Contrary to some beliefs, this practice does not double the cost of development because the resulting code will be
Simple Design – most things are simple when they start out but become more complex as time goes on.
The codebase must be inspected regularly for signs of complexity and the code refactored to produce
Test-Driven Development (TDD) – This practice requires that no line of production code is written unless
an ‘automated’ test has been written for the functionality, the test has been run and fails and only enough
The practice does require the use of an Integrated Development Environment (IDE) that supports TDD or access to
a TDD framework that supports the programming language being used.
Rigorous, regular refactoring – As stated in most of the practices above no line of code can be
considered ‘finished’ until the end of the Product Development. Even during a Product maintenance
phase, the code may need to be modified. If ‘patches’ are added just to make the code work, the codebase
Continuous integration – Even code that works in the IDE and passes all tests, it may fail in the system
build; the longer you leave it between system builds (integration), the harder it is to track down what
Integration system builds should be done as often as practicable to catch errors early and make them easier to find
and fix.
Some organisations do a full build of source code that has been checked-in to the source code repository every 2
hours; some organisations do a full build each time code is checked-in to the source code repository.
This practice does require the use of automated system build systems.
How can I help the Product Owner create the Product Vision with the Development Team?
Definition:
Firstly, we must define what the Product Vision is. Just as any Vision, the Product Vision should be a short
statement of what the product is for. Here are some characteristics of a good Product Vision:
One sentence
Colourful with a logo – for Product Visions that are up on the wall
Written in the present tense – imagine that the product already exists
What does the product do – not how it was created or how it works
Roman Pichler, the acknowledged father of Visions, says that Product Visions should be:
Clear & stable: Every participant should find it easy to understand, so avoid empty phrases that don’t say
anything (aka bullshit)
Broad & engaging: It should depict a higher picture that everyone can relate to and that inspires people to
Achievable: Although a vision should be a futuristic idea of what the product might become, set a goal that
can be met
Insightful: Craft the idea based on users’ needs and motives and define the main reason behind the
product’s existence.
Examples
Before investigating how to help the Product Owner create the Product Vision with the Development Team, let us
Tesla:
While doing above, also provide zero emission electric power generation options
Whilst this Vision ‘breaks’ the one sentence guideline, it does fit Roman Pilcher’s advice.
Ikea:
“At IKEA our vision is to create a better everyday life for the many people”
This is a short and broad Vision for the company that will drive the products that the company produces ie will a
proposed product help ‘create a better everyday life for the many people’.
So how does the Product Owner, who is responsible for the Product Vision, go about creating the Product Vision?
Firstly, the creation of a Product Vision is best done collaboratively; as a Scrum Master, arrange a facilitated
workshop with the Product Owner, relevant stakeholders and the Development Team to ‘brainstorm’ ideas; you
may facilitate the workshop yourself (see Creating A Shared Vision That Works).
There are 2 widely used ‘models’ to use to help create a Product Vision:
The idea behind the Elevator Pitch is to put together a statement about something to ‘pitch’ to the CEO when riding
in an elevator; we are not going to do this; it is the elements of an Elevator Pitch that we need to explore for the
product so that we can come to a suitable form of words for the Product Vision. There are different lists of Elevator
Pitch elements; for now, we will look at the following list from Roman Pichler:
The Needs – the main problem the product addresses or the primary benefit it offers
The Product – summarises the three to five features of the product that make it stand out and that are
The Business Goals – explains why it’s worthwhile for your company to invest in the product. It states the
desired business benefits, for instance, increase revenue, enter a new market, reduce cost, develop the
By ‘brainstorming’ the above elements, the workshop participants get a better understanding of the product and can
Roman Pichler has a downloadable Product Vision Board that you can use to organise the ‘brainstorming’ ‘sticky
In a facilitated workshop, the participants imagine the product to be a ‘shrink-wrapped’ physical box containing the
There is a good description of how to run a Design the Box workshop at Design the Box.
Again, as with the Elevator Pitch, the workshop participants get a better understanding of the product and can
How can the Product Owner and Development Team move from the Product Vision to the Product Backlog?
It is not advisable to go straight from the Product Vision to collecting requirements for the Product Backlog.
The Product Owner (PO) is solely responsible for the value produced by a Product Development and to have some
understanding of this value the Product Objectives, Benefits and an initial Business Case should be investigated to
check that, in all probability, the product will produce value for the company; it is no good having a great product if
no one will buy it and/or it will take 5 years to recoup the development costs.
To help the Product Owner and Development Team move from the Product Vision to the Product Backlog, as a
Scrum Master, you can arrange a series of facilitated workshops to determine the Product Objectives, Business
Product Objectives
The Product Objectives are a list of things that enable the meeting of the Product Vision. It should not be a long list;
Some examples:
Although a Product Vision may state some development attributes that can be measured, most do not; it is the
The Objectives list may also be ordered by business value and may define what is to be included in a Minimum
Benefits
From the Objectives list, we can now make an estimate of the expected benefits that we expect the product to give
to the ‘customer’ (internal and/or external) and the company; each Objective may contribute to more than one
category of Benefit; for example, an Objective of “Reduce report creation time by a minimum of 50%” may have
Reduced staff frustration: reduced staff turnover and recruiting/training costs = 20%
Although we have used percentage values in the examples above, it is recommended that actual monetary values
are used.
Business Case
Now that we have the expected Benefits from developing the product, we must now estimate how much it might
cost to develop.
At this point, the Development Team may not have been chosen:
PO, relevant stakeholders and senior ‘technical’ personnel to investigate the probable costs of:
Doing nothing: Although the immediate cost of doing nothing is zero, doing nothing now may have
From these investigations, the workshop participants must decide as to which option will give, potentially, the best
value.
The costs of the potential solution option must be compared with the expected benefits to make a cost-benefit
See the APM website and other websites for more detailed information and ideas.
Product Backlog
Once the Business Case has been approved, the PO can turn his/her attention to creating the Product Backlog.
As the Scrum Master, organise a facilitated workshop to include the PO, relevant stakeholders and the Delivery
Team to discover the Product Backlog Items (PBI), usually User Stories, that will fulfil the Product Objectives.
These PBI will be estimated by the Development Team and the results fed back into the Business Case to ensure
What may be the benefits of having the Product Owner included in Retrospectives?
The Sprint Retrospective is a key ceremony for ‘Inspect and Adapt’ to aid Continuous Improvement.
Many organisations have only the Development Team, facilitated by the Scrum Master, to reflect on their past
Strengthen the relationship with the Development Team and improve collaboration with them:
Is communication between the Development team and the PO open, honest, and trustful?
Understand why the Development Team requires some time in the next Sprint to carry out improvements
Too big
Does the team know how the users employ the product?
Do you get enough support from the team to “refine” the backlog?
If the Development Team have ‘a problem’ with the PO, it is tempting for them not to invite the PO to
Retrospectives but this ‘problem’ is an issue and as a Scrum Master it is part of your responsibility to help resolve
issues; the Retrospective is the best mechanism to discuss and resolve problems between the Development Team
Which techniques can be used during a Backlog Refinement session to create Sprint ready Product Backlog
Items?
The Product Owner (PO) is responsible for all of the Product Backlog Items (PBI):
The Development Team are responsible for estimating the size and complexity of each PBI; this will be done
During the development Sprint Planning, the Team must select the next highest value PBI to be attempted during
the Sprint.
However, as time goes on, the PO and Development Team need to apply any lessons learned from development so
far to ensure that the candidate PBI are sufficiently well described and sized (but see Scrum.org Myth 14); this
‘confirmation’ is done during Backlog Refinement during which the following questions are answered:
Is the wording of the PBI sufficient for the Development Team to understand what is required?
Are the Acceptance Criteria for each PBI complete and understandable to the Development Team?
Is the initial size and complexity estimate for each PBI still valid?
Are all the candidate PBI sized adequately? – A PBI that cannot be completed in 1 Sprint is too big and
must be decomposed
Is the Product Backlog ordering still correct?
All of these criteria and others to suit a specific situation can be documented as a ‘Definition of Ready’ checklist.
There are a series of blogs that make interesting background reading: Product Backlog Refinement explained. See
Techniques
Run the Backlog Refining session as a facilitated workshop, timeboxed to 2 to 3 hours or 10% of the
Development Team capacity for a 2-week upcoming Sprint (see Product Backlog Refinement: Make the
Most of It)
‘Modified’ Planning Poker:
Acceptance Criteria – use ‘modified’ Planning Poker technique with Development Team members and
PO
Sizing – use ‘modified’ Planning Poker technique with Development Team members (see also Resizing a
Ordering:
Ask PO if there are any business value changes that require the Product Backlog to be reordered
Ask the Development Team members if any PBI changes introduce new dependencies
Spikes – if the Development Team do not fully understand a PBI or unsure how it might be developed,
they can choose to introduce a ‘Spike’ item to the next Sprint Backlog to do some research into the
problem
An extension of Test Driven Development that requires the use of specialised development tools
Although using BDD requires a toolset that might not be available, you can use the structured language to create
An example:
For many years, business stakeholders have seen or been involved with building products using the so-
called ‘waterfall’ model; business stakeholders are intensely involved at the beginning of the
development to specify the detailed requirements and do not get involved again until just before
People get used to a way of working even if they experience problems with it; it is human nature to ‘get
on with it’ and/or develop personal ways of mitigating the problems that they experience.
Many business stakeholders are sceptical about ‘wholesale’ changes to the way that they are being
asked to work especially as, superficially, their involvement with the product development is significantly
increased.
Also, many senior business managers are risk averse and require predictability from the product
development process.
The reasons why the waterfall development model evolved are beyond the scope of this question; to
explain Agile to a business stakeholder, you need to know the major elements of the waterfall model that
Gathering detailed requirements takes a significant amount of time where money is being spent
difficult
If the changes are not implemented, the business get the ‘wrong’ product
If the changes are implemented, it leads to extra cost and delays in deployment
The project plan, created just after requirements gathering, is based on estimates but is taken as
a quote by many which leads to ‘recriminations’ if the development costs more and/or takes
longer
Each business stakeholder will have had frustrations based on one or more of potential waterfall
problems; before trying to explain the whole of Agile, it is recommended to start by discovering which
areas of the waterfall development process is causing the frustrations and explaining the aspects of Agile
One model of product development to base your explanations around is ‘The Iron Triangle’
Waterfall sets out to define all the detailed requirements and plan how they will be implemented; the
resulting ‘contract’ assumes that features, time and cost are all fixed.
However, as already said, it can take a long time to capture the detailed requirements and plan their
implementation; however, things never go according to plan (requirement changes, staff changes) and
so, when trying to implement a ‘fixed’ requirements list, the result will probably be time and cost
overruns.
The business fixes the time for the product development; this time is based on business
The development costs, which are mainly made up of developer costs, are fixed by having a
The requirements variability is based on ‘high-level’ requirements and needs some rules to give the
business some confidence; the main rule is the Minimum Viable Product (MVP).
One of the major advantages of an Agile product development process over a waterfall one is that the
product is delivered incrementally allowing some return on investment before the product is ‘completed’.
Incremental delivery can also help with experimentation when the product details are unclear; parts of
the potential final product can be deployed early to get ‘customer’ feedback that will help produce a
better product.
One of the important factors when explaining Agile to a business stakeholder is to make sure that they
understand the major differences in output that they can expect compared with waterfall and the
Documentation will be minimal focusing on what is needed not what might be needed
Probable participation throughout the development for discovering detailed requirements,
Another approach to answering this question can be found at How to Explain Agile to Your Stakeholders.
What are the typical organizational impediments that Scrum Teams face and how can they be addressed?
There are many opinions as to what the ‘typical’ impediments that Scrum Teams face are; the following list is not
exhaustive but covers the impediments that Scrum Teams may probably face:
Old Habits – During the early stages of an Agile Transformation, when many parts of the organisation are
not conversant with the implications of Agile, some business and technical managers expect the Scrum
Team to deliver documentation and reports that they are used to. This can be either impossible or time-
wasting.
Also, when Development Team Members, new to Scrum, are under ‘pressure’, it is natural for them to revert to old
work practices because they know them and having to think about and use the new work practices takes more time
Solution:
During the early stages of an Agile Transformation, the role of a Scrum Master as the Risks and Issues Manager, is
key.
During the daily Scrum, he/she must listen to what the Development Team members have been working on and
what they plan to be working on; note any item that does not seem to be adding to achievement of the Sprint Goal
and discuss with the relevant developer after the Scrum has finished. If the item is a ‘hang-over’ from the old ways
of working, the Scrum Master must identify the person who asked for the item and engage them in a ‘Scrum
Similarly, the Scrum Master should question any developer that does not seem to be following the Agile and Scrum
practices; for example, the developer may be building the user interface for a User Story from his/her own
knowledge, because it is quicker, without collaborating with a relevant business person to get the correct
information.
Distractions –
In organisations that are used to using Matrix Management for resource allocation, it is usual for one person to be
working on multiple product developments or other work. This causes the individual to become distracted from the
necessary work for any one of their assignments which results in reduced quality of their work and more time
Solution:
Scrum requires that the Development Team is made up of all the skills necessary for the development and that the
The Scrum Master must work with the matrix managers to assign resources to one product development at a time
for the long-term and not assign people based on short-term expediency.
There may be occasions when a particular Development Team member is considered to be the only person who can
solve a problem outside of their immediate product development responsibilities; as long as this is to be a short-
term (1 to 3 days) commitment, it is allowable but their reduced development capacity must be reflected in the
Team’s expected velocity. If this situation is a common occurrence, it is a significant impediment to the Team’s
progress and the Scrum Master must escalate the impediment to the Product Owner.
Lack of cross functional teams – In the waterfall model of product development, the ‘team’ is not
The team member skills are different for each ‘phase’ of the waterfall development process, whereas with Scrum
we require all necessary skills to be available at all times throughout the development:
Solution:
As in Distractions above, the Scrum Master must work with the organisation resource allocators to ensure that
Scrum Development Teams are composed of members with all the necessary skills for the development all of the
time.
Old HR Systems – The traditional HR system for compensating employees is based on the individual;
their skills, their seniority, their responsibilities. This is particularly true of ‘Performance Related Pay’; it
is a competitive system.
We expect Scrum Development Teams to be self-organising, cross-functional and work in a collaborative manner;
Solution:
The Scrum Master must work with the HR department to make them more Agile. There is a good article from the
Agile Alliance, Practicing Agility in Human Resources, to help with this HR coaching.
ScrumBut –
The ‘mechanics’ of Scrum are relatively easy to implement but it is implementing the Agile values from the Agile
Manifesto, the Agile Principles and the Scrum values from the Scrum Guide that make Scrum work; these values
are principles are the hardest part of Scrum to implement because they require an organisational culture change.
Many organisations implement the Scrum ‘mechanics’ and ignore the values and principles and then wonder why
Solution:
It is recommended that the Scrum Master, during the early stages of an organisational transformation, focus their
‘culture changing’ efforts on the stakeholders directly involved with a single product development.
Some may be sceptical so the Scrum Master may have to spend a significant amount of mentoring time with them.
Even though the Scrum Master may explain the implications of Scrum to sceptical stakeholders (and developers in
some cases), some people do not believe until they see the results. Be prepared to answer all the sceptical people’s
In ‘traditional’ organisations where there are many meetings, many required meeting attendees get bored and turn
up late because they know that the early Agenda items probably have nothing to do with them.
Solution:
When more than two people are required to discuss a topic or make decisions, hold a facilitated workshop.
Although some say that a facilitated workshop should have an Agenda, the word ‘Agenda’ still indicates to some
that a facilitated workshop is just another name for a meeting. Instead, have clear workshop objectives which are
tightly focused around a single topic so that all workshop invitees are motivated to attend on time.
For those people who still consistently turn up late, the Scrum Master must individually mentor the person as to
They may miss something that their input to the discussion would be vital
Asking to recap what has been discussed in their absence wastes other peoples’ time
Blocked Work – The development Team will rely on people who are non-team members for information
or reviewing of work before they can move on. Sometimes these people consider their primary
responsibilities to be more important than their product development contribution or their supervisors do
This results in ‘blocked work’ and will probably be ‘reported’ during the daily Scrum.
Solution:
The Scrum Master, as the Risks and Issues manager, must work with the affected developer to resolve the problem
and if the resolution is not successful, he/she must escalate the problem to the Product Owner (PO) who may have
to use their seniority and company politics to resolve the problem themselves.
Remember that the PO is solely responsible for ensuring the best business value emanates from the product
product development solution that they have to integrate with being supplied by other teams; these teams
The suppliers may or may not be using Agile or specifically Scrum for their development work.
The other teams may deliver their parts late with respect to the plans or the delivered part may not be of
suitable quality.
Solution:
The process for dealing with Supplier Issues will probably be different between ‘internal’ and ‘external’ suppliers.
For ‘internal’ suppliers, the first action would be for the Scrum Master to discuss the problem the Project
For ‘external’ suppliers, the first action would be for the Scrum Master to approach that part of the
organisation that let the contract to discover the dispute process and to follow that
In both cases, if resolution is not possible and given that there is Programme Management in place, the Scrum
Master should escalate the problem to the PO and facilitate the problem resolution with the Programme
Management.
It is often tempting to see the immediate symptoms of a problem and fix things so that these symptoms disappear
To successfully solve problems, we must get to the root cause of the problem; so-called Root Cause Analysis
(RCA).
Brainstorming
Brainstorming the RCA relies on several people producing their thoughts and feeding off other people’s thoughts in
data.
The 5 Whys
The 5-Whys technique is possibly the simplest RCA technique; it is a little like an annoying 5-year old asking
question after question to the answers you give them. Essentially, the RCA workshop facilitator keeps asking
Generally, a minimum of 5 ‘Why?’ questions are asked, although sometimes more or less may be needed. For
example:
o Why? - The alternator belt was well beyond its useful service life and not replaced
o Why? - The vehicle was not maintained according to the recommended service schedule
This example could be extended to discover why the vehicle had not been maintained properly; the root cause could
be that the need for regular servicing was unknown; the questions go on until the group agree that a fixable cause
has been found.
Flowcharting
Flowcharting can help discover problems about a process in a graphical manner; a group of people affected by the
problem will chart the supposed ‘As-Is’ process to see where the problem has arisen:
Someone does not know that they have responsibilities in the process
A vital step in the process has been left out or is not being ‘run’
Fishbone Diagrams
A Fishbone or Ishikawa Diagram is most useful when the “5 Whys” technique is considered to be too basic. In a
Fishbone Diagram, the various causes are grouped into categories, with arrows in the image indicating how the
causes flow toward the problem; categories used in the diagram are not pre-defined but common categories include
This type of RCA seeks to understand the possible causes by asking questions such as “what actually happened,”
“when,” “where,” “why,” “how,” and “so what” until a possible cause is identified and the consequences and
Affinity diagrams
An Affinity Diagram is a tool that gathers large amounts of language data (ideas, opinions, issues) and organizes
them into groupings based on their natural relationships. The Affinity process is often used to group ideas
generated by Brainstorming.
The senior management of some (if not many) large organisations, having accepted the ideas behind Agile and
knowing that the one-team Scrum framework is inadequate for their organisation, try to go straight from a
tin’.
Implementing the cultural changes required for single-Team Scrum is difficult enough; the problems with trying to
implement the cultural changes required for ‘Scaled Scrum” are exponentially more difficult.
Don’t try to scale when you are first starting out –
When beginning the agile journey, it’s critical that you start small and master the basics. Introducing a large
enterprise framework with multiple dependencies presents a steep change curve and typically requires extensive
investment.
In the early stages, you will reap greater benefits if you focus on developing the core agile principles and Scrum
Values
Work on developing a good backlog, meeting commitments, reaching a standard velocity, and achieving high-
quality output.
Additionally, starting small creates excitement, focuses on quick wins and learning more nimbly.
You may have reached the stage where you have multiple Scrum teams, that are working well in a Scrum
environment and have started introducing larger epics that could benefit from being split across multiple teams.
This may seem like a natural point in the journey where you may start to ask whether you are ready to scale.
Before taking that leap, it is strongly recommended to optimise your current Scrum teams and Agile processes;
really concentrate on strengthening your base in order to maximize throughput and ROI—instead of trying to build
the product-development processes that you will need for Scrum at scale.
If you are at this point in your Agile journey, take a look at implementing test-driven development, continuous
integration and deployment (not included in the Scrum Guide) and meeting commitments on a regular cadence.
Don’t do it just to do it –
Scaling Scrum has become incredibly popular in many industries; SAFe is a buzzword in the agile community;
companies that are truly ready for enterprise frameworks are getting major rewards from them but that by itself is
The transition from team-level Scrum processes to an enterprise framework requires a significant investment in
change management. The move should be well thought-out and cautiously approached. If you have specific
problems that scaling can solve, lay them out with an advisor and see if the journey is worth the investment.
When you’re ready, know that enterprise frameworks are tried and true tools that have delivered tremendous
benefits for many organizations but you have to be at the right point in your journey to take advantage of these
tools.
When a product is being developed by multiple Scrum Teams it is recommended that there be 1 Product Backlog
(PB) for that all the Teams draw from to produce their own Sprint Backlogs.
It is probable that 1 Team may be dependent on an output from another Team before they can develop a particular
Suppose that part of the product being developed requires a customer to pay for goods/services; we may
“As a customer
At some point in the development it is realised that there are so many ways to pay (credit card, debit card,
PayPal, WorldPay etc) that the User Story could not be completed by 1 Team in 1 Sprint; ie it is an Epic
It is decided to split the User Story above into 1 User Story for each payment method
It is decided that the MVP for the next release includes paying by credit card and paying by PayPal
It is further decided that Team A will develop all the common elements of payment as part of developing
the ‘Pay by Credit Card’ functionality and Team B will develop the ‘Pay by PayPal’ functionality, which
Clearly, Team B has a dependency on Team A such that Team B cannot start their part of the payment functionality
When Scaling Scrum, the aim of Release Planning is to minimise the inter-team dependencies; it is improbable that
The following are some of the ways that inter-team dependencies could be handled:
Ensure that all candidate features and User Stories/Epics are decomposed to manageable sized User Stories
Assign User Stories to potential Team Sprint Backlogs keeping in mind any dependencies
Highlight dependencies
For the payment example above, you may end up with a Release Plan Board and proposed Team Sprint plans that
You can see that all Release MMF are planned to be finished by the end of Sprint 2 leaving Sprint 3 to cater for any
overruns.
Team Structuring
With the advent of Component-Based Development (CBD), some organised their development teams into
Component Teams and Product Teams who ‘glued’ together the necessary components.
If this continued into an Agile environment, then each ‘product’ development team would be dependent on separate
In an Agile environment it is recommended to have ‘Feature Teams’; 1 Team should be responsible for the end-to-
This does not preclude the reuse of components; part of the organisation’s Design Strategy would require that a
separate (possibly non-Agile) Component Management Team (CMT) reviews the output of the Development
Teams to see if there is any functionality that could be componentised; the CMT are responsible for
useful.
Component Teams
Feature Teams
Scrum of Scrum meetings are conducted at regular intervals, probably at least once per week, to track dependencies
Dependency threads or tags may be used for visualization of dependencies among features and/or teams.
As part of Agile programme management, “independent” dependency teams may be used to track inter-team
dependencies, blockers, external dependencies and ensure they are taken to closure.
This obviously requires a larger than normal space but the format used is important as well to maximise the value
of the ‘workshops’; for example, for a Sprint Review where several Teams are ‘show-casing’ what they have
produced, it would be boring for the stakeholders just to sit through multiple presentations and demonstrations
especially if there are features being reviewed that they have no immediate interest in.
Scaled Scrum Events/Ceremonies are best run if everyone is co-located or can travel to the Event. This is not
always possible or economical for organisations that have programme Development Teams and stakeholders
The overall Programme Scrum Event process is similar for both non-co-located and co-located Events:
1. All participants attend an opening session where the objectives and specific process for the workshop are
explained
2. Depending on the needs of the workshop, all participants may stay ‘together’ for the whole workshop
(unusual) or ‘break-out’ sessions may be held that focus on specific workshop topics; anybody may attend
3. If ‘break-out sessions are used, then it is usual for all participants to come ‘together’
4. At least once during the Event for ‘catch-up’ and information sharing. There may be discussion about
5. Toward the end of the Event for ‘catch-up’, information sharing and conclusion purposes
Non-Co-Located Programme
For non-co-located Teams and stakeholders, use should be made of tele-conferencing and video-conferencing
technology.
Scheduling of combined and ‘break-out’ sessions can be difficult if the Teams and stakeholders are in widely
different time zones; what would normally be a half-day Event may have to become a full day or even a day and a
half.
Co-Located Programme
For a co-located programme and stakeholders, it is essential that the ‘main room’ is big enough to hold all
participants and is equipped with white boards and flip charts. If the room is really large, then a big screen and PA
The ‘break-out’ sessions may be held in the same room; some or all may be held in readily accessible smaller
rooms.
‘Big-Room’ Formats
The detail of how the ‘big-room’ Events may be run and facilitated vary but the 2 most common are Open
Space and World Cafe.
The following are how the ‘standard’ Overall Programme Scrum Event Process may be configured for specific
Events:
Release Planning
For one-Team Scrum we would only plan a Sprint at the beginning of a Sprint wherever we are in the Release cycle
but for a programme, the stakeholders will need to have some idea what will be in the Release and the Teams need
to produce outline Sprint Plans so that dependencies between Teams may be discovered, minimized and planned
for.
Before the joint planning session, the Programme Manager will have worked with the relevant stakeholders to set a
Release Goal and select potential features for the Release ordered by business value.
At the start the start of the Event the Programme Manager may allocate potential Release features to Teams or the
The Teams, aided by relevant stakeholders, will go into concurrent ‘break-out’ sessions to decompose the features
into User Stories and estimate the total effort required for each feature; this activity should be timeboxed to reduce
The Teams will come together to see each other’s list of User Stories, to identify dependencies and distribute User
The Teams then go back into ‘break-outs’ and produce an outline Sprint plan for each Sprint in the Release.
Finally, everybody comes together to produce/update the Release Plan Board with the outline Team Sprint Plans to
ensure that the highest value User Stories will be developed first and that inter-Team dependencies have been
catered for.
Sprint Planning
Some Programme Teams hold their individual Sprint Planning in the same space but separately and then ‘compare
notes’ toward the end of the session to ensure that dependencies have been identified and catered for.
Daily Scrums
Some co-located Programme Scrum Teams hold the daily Scrums at the same time and in the same space but
separately, then each team summarises any highlights to the other Teams.
Other organisations hold their Team daily Scrums as ‘normal’ and the Scrum Masters have their own ‘daily Scrum
Sprint Reviews
A programme Sprint Review involves all Teams and all relevant stakeholders so the large space is needed for a co-
located programme.
The workshop starts with the Programme Manager summarising what has gone on in the Sprint then the
stakeholders attend as many Team demonstrations and hands-on trying of functionality as ‘break-outs’, held either
in the same space or readily accessible ‘break-out’ rooms.
There are usually white boards and/or flip-charts available for stakeholders to make notes about things that they
would like to be discussed toward the end of the Review when everybody comes together again.
The final ‘all-together’ session also includes the Programme Manager asking the stakeholders if there are any
features/User Stories that need to be added to the Product Backlog; if there is anything that needs to be deleted from
For non-co-located Teams and Stakeholders, the individual ‘break-outs’ can be run as concurrent timeboxed
‘webinars’ at scheduled times throughout the Review session; each Team running several ‘webinars’ to allow as
Sprint Retrospectives
Although each Programme Scrum Team may hold their own Sprint Retrospective, it is important that a Programme
A Programme Sprint Retrospective follows the Overall Programme Scrum Event Process described above; the
opening session is used to identify the good and bad things about how the programme is running and choosing the
Each ‘break-out’ session focuses on one area of issues and any members for any Team attempt to find the root
There may be an interim coming together to discuss progress so far and maybe add to or subtract from the list of
During the final coming together, the results of the ‘break-out’ sessions are discussed and plans are devised to
What techniques can I use to effect change in an organisation to help Scrum Teams be more productive?
Scrum Team productivity is difficult, if not impossible, to measure for a single Team and definitely impossible
The metric that Scrum Teams usually use to help them plan Sprints is the Development Team velocity; some
‘managers’ believe that Team productivity is directly linked to Team velocity; the higher the velocity, the higher
the productivity.
Velocity is Team, product and time specific and should only be used to aid Sprint planning.
The value that a Development Team is delivering per Sprint cannot be used as a measure of productivity either; by
its very nature, a Team will deliver higher value at the start of the product development because they will be
Increasing Scrum Team productivity can only come from ensuring that the fundamental ‘rules’ and ‘values’ of
The following are the main areas of organisational change that will help improve Scrum Team productivity:
Senior Management Awareness and Involvement – In the 2015 State of Scrum Report it was stated that:
“Respondents report that senior management sponsorship and support is far and away the most important factor in
adopting Scrum.”
AND
“… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported
The need for senior management Agile awareness and involvement in product development is that Scrum Teams
are not isolated ‘islands’ in the organisation, they have to interact with other parts of the organisation that may
resist changes to their work practices for the Scrum Teams to be productive.
The motivation for these other organisation parts to adapt must come from senior management.
As an example, an Agile Team was formed to implement a new process to get connecting passengers from one
aircraft to another, especially if the inbound flight was delayed. The new process involved the development of a
new IT system and the team planned to release increments of the new software monthly.
However, when it came to the first release, the team discovered that there was an organisational process that
The problem was resolved eventually by allowing the team to have a ‘fast-track’ release process but the resolution
took a month of discussions with the management of 3 other divisions within the organisation.
When an Agile/Scrum transition starts, it is important to discover all the stakeholders, at whatever level in the
organisation, that can influence the early team’s productivity and ensure that they understand the possible
Mark Levison suggests one way of coping with the necessary senior management ‘education’ in his blog, Taking
Organizational Improvement with Scrum Seriously; he proposes a ‘Change Management’ Scrum Team to develop
Keep Teams Together – The ‘traditional’ approach to product development is to create a project, assign the right
people when they are needed throughout the project; there is never one coherent team; ie ‘bring people to projects’.
The Team members in Agile have all the skills needed to complete a product development; the Team size is
If we take Tuckman’s group dynamic model, all groups of people go through ‘forming’, ‘storming’ and ‘norming’
‘phases’ before the group becomes ‘performing’; it can take a significant amount of time before the ‘performing’
stage is reached.
It therefore follows, that once a Team has reached the ‘performing’ stage, we should keep the Team together after
the product development is finished; the ability to work well together as a team is more important than any
individual skills.
Keeping teams together can be characterised as ‘bring projects to teams’.Allow the team to determine their Sprint
capacity – Some Product Owners (PO) ‘cajole’ some Development Teams to take on more work in a Sprint than the
They know it ‘won’t’ happen and that they will be blamed. They become demotivated and do not work
productively
They try to work faster to complete the work and cut-corners, producing low quality outputs. Overall team
The team must be allowed to do their own estimation and set their own ‘comfortable’ Sprint capacity; the
Team members must collectively believe that a Sprint plan will work at the end of Sprint Planning.
Do not add work during the Sprint – The aim of Sprint Planning is to set the Sprint Goal and add the
relevant Product Backlog Items to the Sprint Backlog that will contribute to the Sprint Goal.
There are still many established ‘Agile’ organisations where it is normal for Development Teams to
receive extra work during the Sprint from different people, most of which does not contribute to meeting
To be productive, a Development Team need to keep focused on the Sprint Goal, distractions reduce
Most of this extra work can be categorised as ‘fire-fighting’; there are 2 approaches to resolving this
‘problem’:
Form a ‘fire-fighting’ team to deal with ad-hoc work
Find the root cause of why this extra work is needed and fix the root cause problem.
Allow the Team to add improvement work to the Sprint – A common management misconception about
Sprint Planning is that all the chosen Sprint Backlog Items (SBI) must be completed; the total chosen SBI
Not only is this unreasonable, because the effort for each SBI is only an estimate, but it also leaves no
room to implement any of the improvements that were identified during the previous Sprint Retrospective.
A reasonable agreement must be made between the PO and the Development Team for an agreed number
The Scrum framework is defined in The Scrum Guide; maintained and published by Scrum.org.
To get an answer to this question you must first ask the question ’What is Agile?’.
The definition of Agile is owned by the Agile Alliance that was formed in February 2001, at Snowbird, Utah. The
first Agile Alliance publication was the Manifesto for Agile Software Development closely followed by the 12
Principles Behind the Agile Manifesto.
So, to answer the question, the Agile Manifesto and Principles are listed below with the explanation of how the
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan That is, while there
is value in the items on the right, we value the items on the left more”© 2001, the Agile Manifesto authors.
These are the 4 Agile Values and any product development framework that purports to be ‘Agile’ must embody
It is worth noting here that although the Agile Manifesto specifically talks about ‘software development’, the Agile
Agile Manifesto explanation and how Scrum embodies the Agile Values
1. Individuals and Interactions: There must be advice about how the people involved interact and communicate:
Scrum defines the roles for product development and specifies the necessary individual and group interactions.
2. Working software: The product development team’s focus must be on producing working increments of the
3. Customer Collaboration: The best results for product development come when all those involved work
together as one ‘team’ to solve problems whether they be business or technical people and whether they are internal
Scrum defines a Scrum Team that includes business and technical people.
4. Responding to change: The major drawback to ‘waterfall’ processes is that they recommend obtaining all
detailed requirements before development starts and create the development plan; ‘contracts’ are set in place and
organisations think that they have a high degree of functional, time and cost predictability. However, as we all
know, the development team discover hitherto unforeseen problems and the business change their minds. To cope
with this situation, ‘waterfall’ processes introduced ‘Change Procedures’ which became bureaucratic and time
wasting.
Scrum uses a high-level ‘requirements list, the Product Backlog, ordered by business value the content and ordering
of which is the responsibility of the Product Owner. Furthermore, the Scrum framework has frequent, short events
that include consideration of recommended and requested changes to the Product Backlog.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
The Scrum framework recommends that product development takes place with short, 2 to 3-week
development periods, Sprints, that result in a working increment of the required product.
If appropriate, the increment may be released to the live environment at the end of a Sprint or the
2. Welcome changing requirements, even late in development. Agile processes harness change for the
The Scrum framework recommends that the product development requirements defined before
development begins are of the lowest level of detail of the names of the business processes necessary for
At regular intervals, at least once in every Sprint, consideration is given to requested changes to the
requirements and ordering. The result is that the highest business value is achieved in any given
timeframe.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
4. Business people and developers must work together daily throughout the project.
Scrum defines a short, 15-minute, daily event called the Scrum, when all Development Team members,
both business and technical and whether full or part-time, come together to state what was done during the
previous day and what is planned to do for the next day. Also stated are any problems that individual
Any discussion of ‘matters arising’ from the daily Scrum event are conducted after the Scrum has ended.
5. Build projects around motivated individuals. Give them the environment and support they need and
The Scrum framework does not recognise the term ‘project’ preferring to focus on product development
However, Scrum does implement the spirit of this Principle in that it recommends appropriate
empowerment to the Scrum Team and encourages cross-functional, self-organising Development Teams;
the day-to day work of the Development Team is the sole responsibility of the Team and not a ‘project
manager.
6. The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.
The Scrum framework defines all the events when the Scrum Team and stakeholders must come together
to plan, refine and review the work and to reflect on the detail of the day-to-day activities being followed;
However, much of today’s product development involves people in geographically dispersed locations and
Although not part of the Scrum Guide, most Scrum practitioners take advantage of the abundant video-
conferencing and desktop sharing facilities available from secure internet environments.
The Scrum framework requires that the product increment requirements that are developed in a Sprint must
pass the quality criteria defined in a ‘Definition of Done’ to be considered complete and fit for
demonstration to stakeholders.
Organisational product development progress is measured by the number of requirements that have been
completed; task and activity progress, if used, is the sole responsibility of the Development Team and is
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
However, it is part of the Scrum Master’s responsibilities to remove impediments to the Development
Team’s progress; one such impediment may be that the Development Team as a whole, individual team
It is a proven fact that productivity reduces when people are stressed and tired. The Scrum Master must
look-out for signs of ‘overwork’ in those involved in the product development and help overcome the
problem.
The Scrum Guide does not mention technical excellence or good design specifically.
However, the Guide does require that only “Done” requirements can be demonstrated to stakeholders. The
‘Definition of Done’, the checklist of criteria that defines when a requirement is “Done”, will vary from
product to product and organisation to organisation but will most probably include technical excellence and
10. Simplicity--the art of maximizing the amount of work not done--is essential.
This is a widely misunderstood Principle but essentially means ‘only do today what is essential to do
today’. For example, is it essential to gather all of the detailed requirements before development work
begins? The answer is no; we gather the most important requirements at a high-level of detail; these may
change over time and the time taken getting the details ‘up-front’ will be wasted.
All of the aspects of the Scrum Guide embody a minimalist approach to the amount of work to be done.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behaviour accordingly.
The Scrum Guide defines the Sprint Retrospective event where the Scrum Team inspects itself and creates
Acceptance criteria are sets of statements with clear pass and fail result that specify both functional and
nonfunctional requirements of the user story. It acts as a guiding force for the developer to know on what basis their
delivery would be evaluated for completion and correctness. Acceptance criteria is a set of expectations end user
has from a certain feature or a user story. It is the responsibility of Product owner to create the acceptance criteria
For example:
As a teacher, I want to generate the assessment report so that I can evaluate the student performance. Acceptance
4. Display error message if the service is not working. (If the team chooses error message as a part of the
It applies to all the product backlog items It applies to specific product backlog item as it clarifies one item
It does not change very frequently, not Acceptance criteria is negotiable between product owner and
expected to change during the sprint development team.
Meeting Definition of Done means meets Just meeting acceptance criteria not necessarily means that
the acceptance criteria definition of done has also met.
It serves the purpose of making the It serves the purpose of clarifying the business requirements and
unambiguous understanding of any product conditions, which must be met to satisfy the users for a given
backlog item can be declared complete. requirement.
Would it bother you if your Scrum Master suggests a course of action concerning product development?
Alternatively, Can a Scrum master pitch in regarding Product Development ideas and suggestions?
A Product owner’s primary responsibility is to make sure that the incremental delivery provides continuous and
sustainable value to the customer and a Scrum master’s primary job is to make sure that Scrum team adheres to
There can be times when Scrum team or a Scrum Master want to provide ideas/suggestions with respect to product
development.
In such cases, the discussions should be done in a professional and peaceful manner to evaluate if the suggestions
are actually going to help everyone [including team, PO, Scrum master and Customer].
The discussion can be based on Earned value management concepts, Scrum Values or Agile principles to correct
professional manner
Product discovery means, identifying what are the points, features and functionalities that are going to be useful to
the customer, generate revenue and be realistic in terms of delivery. This requires the plans to be continuously
updated and modified keeping in line with the latest feedback from end users. So this iterative process is known as
Product discovery.
Organizing workshops with the end users and customers to understand their pain points and kind of
Usage of techniques such as wireframes, personas and user stories to help them relate with the proposed
product functionality
With help of incremental delivery, gathering customer feedback to know which of the features they truly
liked and which ones they prefer to receive in the next release is also an important step
This way, product discovery remains an ongoing process during the project duration.
At what stage do you involve the Scrum team in the product discovery process and what are its benefits?
The sooner the Scrum team gets involved, the better it is.
Because Scrum team can also provide view about technical feasibility, cost and risk related estimates that
can help the PO or Sponsor have a meaningful conversation with the customer.
It creates a better understanding of the customer pain points to the Scrum team so they get motivated to
How do you organize a Scrum team’s collaboration with stakeholders — and improve it over time?
Product Owner should arrange for a regular meeting between stakeholders and the team. The Team can ask the
questions related to the requirements and get them clarified. These could be related to UI format or any technical
risks. Sometimes when the stakeholders and product owners have difficulty in deciding the priority of the user
stories but during discussion session with a team which consists of different skill set will be able to decide based on
technical debt or some other hardware issues, which stories can be of high priority and can be delivered in the next
sprint.
User story mapping workshop is very important and should be arranged with the help of the Product Owner and
Scrum Master.
Sprint reviews and demos, release demos, and user interviews are also good venues for improving collaboration
between the Scrum team and stakeholders. Communication and transparency are the keys to achieve collaboration.