Chapter 10 - The Product Managers Role in Development

Product
Management Essentials Chapter 10 – The Product Manager’s Role in Development
CHAPTER 10

The Product
Manager’s
Role in
Development
COPYRIGHT © 2017 BY KEN SANDY. ALL RIGHTS RESERVED. DO NOT REPRODUCE, DISTRIBUTE OR REPUBLISH WITHOUT WRITTEN PERMISSION.

Product Management Essentials Chapter 10 – The Product Manager’s Role in Development
Product Managers Support Engineering

Development

Chapter Goals: Contrary to a common opinion, Product Managers should not see their
role as driving engineers to execute against a given product plan. To do so
1. Understand the role Product Managers play in the creates unnecessary tension, especially if an arbitrary date has been set or
a detailed requirements document, full of features, is suddenly dropped on
Engineering development process them without business or customer context. Instead, see development as a
partnership, where your role is primarily to support the team as needed to
2. Comprehend the basics of Waterfall and Iterative keep them effective, with minimal interruption while working towards the
development methods, especially Agile/SCRUM most important priorities. Any other mindset may be counterproductive.

Start with understanding the structure of your overall product
3. Learn some tips and techniques for overcoming common development process, and define at what points and how you can play a
development process challenges Product Managers face role in empowering Design and Engineering. For example:
Ø Communicate overall goals and vision – so the team understands and
is motivated towards a valuable end-state.
Ø Define, clarify and prioritize requirements – so the team remains
unblocked and can work on the most critical needs.
The Agile Manifesto Ø Provide supporting business and customer context – so the
development team understands why something is important and can
weigh in on alternative solutions or trade-offs.
Ø Own stakeholder feedback and communication – to provide air-cover
for the team and identify changes or potential disruptions.
Ø Blocking and tackling – keep the team focused on priorities by
(co)owning resolution of issues. Don’t become a source of churn
yourself.
Ø Encourage ownership – let Engineering own making commitments,
support them in quality efforts and process improvement, and allow
them to influence product decisions.

In most organizations, achieving these goals is a group effort – Engineering
and UX Management, SCRUM Masters, Project Managers, and experienced
Lead Engineers will be happy to co-own these responsibilities.
Nonetheless, a PM should always make sure these areas are adequately
addressed.

This chapter does not aim to go in-depth on defining all different Introduction to Waterfall Development Methods
development processes used in modern software organizations – there are
plenty of resources for that. Instead, we will introduce two common Traditionally, the Waterfall development approach was the most used in
methodologies (Waterfall, Agile, hybrids) at a high-level, with much deeper software and early internet organizations; and for good reason. In general,
emphasis on a commonly embraced formal process; SCRUM. While most
projects were large – requiring many developers working on the same
organizations customize their development process, many fundamentals of rd
monolithic codebase simultaneously. There was not the plethora of 3
SCRUM, if not the formal structure, can be applied in many situations.
party development, testing and infrastructure tools we can leverage today.
Deployment was more complex and time between upgrades was
Also, throughout the chapter, you’ll see tips and advice on how to be measured in many months (and remains so in many high-risk and legacy
effective; such as where you can engage in the development process to environments). Real-time user data powering continuous improvement
help improve it especially when it seems to be breaking down or shipping wasn’t as rich, and “the cloud” was non-existent. The idea of iteratively
value to customers too slow. The Product Manager is admittedly in an
making changes based on fast learnings was a foreign concept.
unfair position; it is beyond their direct control but nonetheless they are

called to task when product implementation isn’t moving fast enough.
Waterfall still has plenty of supporters and, in certain circumstances, is a
better choice than Iterative methodologies. Waterfall aims to be a
In such a situation, the worst things a Product Manager can do are: predictive (as opposed to adaptive) method for software development. It
- throw their team under the bus (blaming them or engineering starts with analyzing customer requirements and tasks in detail, catering
managers), for known risks, and laying these out in a project plan from beginning to
- attempt to micro-manage engineers directly (driving them towards end. Once an entire product plan is compiled it is easier for Project
specific deliverables, checking in on progress many times a day); or Managers to assign pieces of functionally and technologies to individual
teams for completion “to specification”. It emphasizes consumer and
- set aggressive deadlines in the hope this will create a sense of
market research activities upfront, and internal QA and customer
urgency.
validation later in the development cycle. It provides for distinct phases for

each activity – with hand-offs of deliverables to guide future phases.
Instead, some alternative strategies for a Product Manager are:

- breaking scope down until incremental customer delivery is possible However, little systems-wide working software is produced until late
(even if small). As confidence builds more complexity can be added in. during the life-cycle. And it can be a long time before shipping software to
- encourage investigation into underlying issues such as lack of customers – 6-18 months isn’t uncommon. Once a product is launched, it
development tools, immature testing processes, resource-levels; and may not undergo rapid optimization (usually these are saved for future
identify improvements in regular retrospectives; and major upgrades or point-releases).
- track and draw attention to sources of disruption and time-spent on
non-development tasks (which reduce team velocity). Here are some “flavors” of product, projects or organizations that remain
better suited to Waterfall Methods:
You get the picture – be constructive, supportive, and data-driven… - Requirements are very well understood and unchanging
- High systems complexity with many dependencies
For more in-depth discussion (beyond tips in this chapter) see Chapter 16 –
- Management over very large teams (where you need clear
Working with Engineers and in Chapter 15 – Leading Through Influence.
specifications for the interactions between modules)

- Management over multiple geographies and/or cultures (not co-

located for frequent enough collaboration, requirements must be very
clear to overcome language and other barriers)
- Implementation within, or integration with, legacy enterprise systems
(old code-bases, hard to maintain, don’t use modern software
paradigms such as modularity and APIs)
- Contractual projects with specific needs needing precise cost and time
estimates (RFP’s/bidded projects, outsourcing, government contracts,
large integration projects, traditional clients)
- Systems for high-regulation or low-risk tolerance industries
(healthcare, finance)
- Highly-disruptive products, where the full value of the system isn’t
realized until all the pieces are implemented and working together
(hard to iterate your way there, no value in validating partial solutions
with customers until it is done)

Waterfall is simple to understand – with clear hand-offs and deliverables
between phases (documentation, estimates, plans, designs). Each phase
also represents a gate – with increasing analysis and work complete, each
provide an opportunity for senior stakeholders to decide whether to
ü To avoid over-scoping and scope creep, follow the best practices
continue to move forward. But each handoff can also be costly in
outlined in Chapter 6 –Managing Time-Scope-Quality Tradeoffs.
overhead, without any working code to show for the effort until later in
the process. ü Beware declaring requirements frozen when leaving the
Requirements phase. More accurately requirements are “slushy”
Here is a description of the main stages – naming conventions differ across and incomplete, leading to a typical 30% overrun on time/budget
the industry, but the general purpose of each phase is consistently applied. for the average project. Add a contingency to your timeline.
Product Managers should pay attention to the risks and mitigation
strategies outlined in each phase:
Ø UX and Systems Design – User Experience creates a Functional
Ø Requirements – upfront consumer and market research, followed by Specification showing the experience, detailing the flow, and capturing
requirement definition. These typically result in a Market error cases. Engineering creates an Architecture and Technical
Requirements (MRD) and Product Requirements document (PRD). Specification for the given requirements. Project Management creates
a Project Plan including timeline, streams of work, and dependencies.
Product Management Risks and Mitigation:
ü What the customer will receive is decided upfront so extra effort
should be put in needs analysis and exploring solution options. ü The Project Plan is built on many assumptions. Waterfall is
intended to provide predictability, but often it leads to the

“illusion of predictability” due to a false sense of confidence. Be

War story – Waterfall Project Planning is Challenging
on top of slippage from the project plan, proactively addressing
causes and communicating early.
My client valued upfront Waterfall project planning techniques –
ü Provide User Experience ample time to validate designs, and
reliant on fully-scoped artifacts to make resource projections,
ideally prototypes, with users. To speed timelines, this step is
approve investments, and to set financial expectations (they are
often skipped to later detriment of usability.
a highly scrutinized public company).
ü Provide Engineering with non-functional specifications (such as

security, user loads, uptime, response time) to assist with I led them through developing a product roadmap and evaluate

appropriately designing the system to scale just a little beyond the potential business impact for a major product initiative. It

expected peak demand. Resist attempts to make it future proof. looked very promising. So, I was charged with creating a

complementary resource plan over an 18-month timeline. (I

would have personally preferred a different approach, but

Ø Implementation – The team is building the product now, according to understood this was the decision-making approach for the client.)

specifications, under a timeline. At the start of implementation, the

focus is often on the foundational infrastructure, which will eventually Working through it with even very senior, experienced engineers

work up to features. Generally high-priority core features are and financial analysts was incredibly stressful. Roadmap items

delivered, starting with the most core requirements. Therefore, the had minimal scope defined… yet here we were asking them to

rate of business value delivered (customer valued functionality), peaks estimate effort, cost, and ROI with so little information available.

in the middle of the implementation phase, and tapers off as lower

priorities are added. Unit testing and regular check-in of new code into They constantly asked me to define greater levels of scope but

an integration branch should occur during implementation, since there was neither the time nor resources for this. Therefore, each

catching issues at this stage is much less costly than closer to launch. estimate they provided came with highly variable time ranges or

“confidence levels” that made the whole exercise feel ineffective.

Product Management Risks and Mitigation: And who could blame them, any number of unknowns could have

ü Even with time pressure and delivery of customer facing affected the timeline dramatically. They were nervous about
functionality later in the cycle, don’t skip user validation to inform where these estimates would end-up – if the CEO or board would
incremental changes. See Chapter 9 - Continuous Customer consider them set in stone.
Validation.
ü Implement a formal change control system for considering scope My solution was to build out three versions – an aggressive,
after a project enters the implementation phase. Changes can be likely, and conservative timeline. The engineers and analysts
very disruptive (requiring redesign or recoding). Involve senior- were much more comfortable with that approach since it
level stakeholders to make major change decisions and reflected their confidence levels more explicitly. Instead of risking
communicate impact on timelines and budget. putting the team on the hook, I was able to use these three
versions to drive a more productive discussion about managing
ü As the timeline proceeds, knowing when to cut off new feature
risk, resource level trade-offs, and to test senior management
development is unclear. Trying to include many secondary
comfort with a range of potential financial outcomes.
features leads to diminishing returns (less business value added

per unit of work) as seen in the value built vs. time diagram.

Ø Quality Assurance – This stage tests for functional and visual Introduction to Iterative Development Methods
compliance, and perhaps limited beta testing with end-users. Systems-
wide and performance testing is also performed. Recall the continuous validation process introduced in Chapter 9 – scope a
component of the product, implement, test with internal stakeholders and
customers, and incorporate feedback so you can repeat the cycle with
ü Stop implementation on schedule to allow enough time for greater confidence.
testing and “hardening” of the system. The most common cause
for quality issues and blowing deadlines is cramming more in the
implementation phase at the expense of QA (the next phase).
ü The Product Manager must be very involved in this stage to
decide bug priorities and trade-offs, and declaring what fixes
address the problem adequately and what doesn’t.
ü Monitor the rate at which new high-priority bugs are discovered
vs. addressed. Early on new issues will be found at an alarming
rate, but the turning point comes when the team is successfully
addressing bugs faster than new ones are discovered. By tracking
these rates, tradeoff decisions between quality and last minute
delays become more data-driven.
For many iterative or adaptive product development methodologies, you
can conceptualize them as cycling through the continuous validation
process repeatedly, moving towards an overall business goal. Each cycle
you identify the most key short-term milestones, adapting frequently in
response to changing realities and learnings. By always working on the
most critical priorities you can accelerate and maximize business value
delivery.

Despite the apparent modernism of Iterative methods, both Waterfall and
Iterative methods are quite old, highly evolved models. (Iterative methods
came out of manufacturing environments, such as the Japanese
automotive industry.) The most well-known iterative approach is Agile.
Agile is not a process per-se, but a set of values and principles that guide a
team through how they conduct product development (for example,

embrace change and continuous improvement). Agile can be further

articulated in terms of more formal, prescriptive processes – such as
Ø Launch and Maintenance – safe deployment to production systems, SCRUM, Extreme Programming, and KanBan. In this chapter, we will limit
roll-out to customers, and hand-off to Technical Operations and discussion to SCRUM as it embodies most of the same values as all Agile
Support teams (See Chapter 13 - Launch and Deployment for an methods and is one of the most adopted (yet misapplied).
extensive overview of the role of Product Manager during this phase).

Except for the cases listed in the previous section, most Web and mobile
application consumer and SaaS enterprise services, are better served with
iterative development methods. Increasingly traditional software (where
updates can be delivered over the internet) and even some physical
consumer products (e.g. 3D printing) are becoming candidates for more
iterative methods – albeit at a slower cycle pace. The key is to keep Agile
teams small and focused – the model tends to break down for very large
teams due to the emphasis on collaboration and minimizing hand-offs and
overhead.

Iterative methods differ from Waterfall in some key ways:

Ø Adaptive – iterative development supports a product rather than a
project mindset. This allows more flexibility throughout to adapt
requirements as you learn, given the best information available at any
time, to make decisions to maximize business value.

Iterative methods also have an often overlooked but high-impact
advantage – the ability to continually adapt process. Because a team
will frequently repeat a full cycle (about 20-25 times a year if using a 2-
week cycle), there is significant opportunity to discuss, identify and Agile, however, can provide predictability and (in some ways) at a
implement improvements in how the team is working together. Even superior level compared to Waterfall. This is because it is based on
one to two small adjustments per cycle means the team has actual not planned team throughput. Careful measurement of a
dramatically improved their performance and collaboration over the team’s pace of delivery (velocity) against a set of well-defined user
course of a year working together. stories allow the Product Manager to get a sense of when the full-
product should be ready. As development proceeds, more information
is gathered to increase the level of confidence in dates.
Ø Emergent Predictability – a common assumption about Agile methods
is that they lose the predictability a Waterfall model provides, such as
insight into progressive delivery milestones on a project plan and a Ø Customer Validation – One difference between Iterative methods and
target launch date. Indeed, many poorly implemented Agile processes Waterfall is the approach to quality and testing. Rather than a
emphasize rapid delivery on the “next key priority” while losing sight separate testing phase after the implementation phase, testing is
of the greater vision and measurable progress towards a definitive completed in the same iteration as development. Because testing is
goal. Pure incrementalism can be ineffective (as we shall see later) and done in each iteration, each iteration delivers a small piece of the
a complete lack of timelines drives stakeholders insane (often leading product with high quality and usability. Stakeholders and users can try
to backlash against Agile and a return to more upfront planning). the product increment out for themselves, validate the value, and
provide feedback for the next iteration. Risk is reduced and confidence
builds that the solution will solve the customer’s needs.

In some cases, the team may discover the initial direction is flawed. being delivered. The feedback loop enables the team to validate their
Business value rapidly drops to zero. There is no use continuing the assumptions that they are indeed working on the right priorities.
project further but instead the team re-evaluates and “pivots”. Agile Stakeholders can track progress against working code rather than
encourages “Fail Fast”. meeting project milestones.

Each iteration’s scope is ruthlessly prioritized to achieve a goal. Scope
Development Process Tip #1 for PMs is only locked down at the start of each cycle – and each new cycle is
an opportunity to reprioritize work entirely if needs be. Secondary
Despite their popularity, “Fail Fast” and “Pivot” can be features tend to fall to the bottom of the backlog, and essential ones
misleading concepts. They may lead to a cowboy (along with newly identified needs) float to the top. All these factors
development culture, trying random ideas, perhaps wildly help to focus the team and creates an environment where they are
thrashing between priorities or skipping customer always thinking about the most critical problems to address.
discovery entirely.
The following charts show how rapidly Agile spread through the software
I recommend instead encouraging a culture of “Learn Fast”. industry since it was popularized – especially since 2009. This study by HP
suggests over 90% use Agile in some form. This, somewhat anecdotal,
Go into each iteration with a hypothesis based on an
survey had roughly a third of respondents each for small (<100), medium
understanding of the customer’s needs. Know how you will
(<1000), and large companies. If we were to account for the plethora of
measure success or failure, and explicitly discuss what you VC-funded start-ups the number using Agile would be even higher.
learned so you can incorporate those learnings in the next
cycle. If it turns out your hypothesis is wrong, then it is still However, the data also shows Agile is typically not implemented in its
a good outcome because you learned something new. purest form. Most “agile” organizations – particularly scaling or larger
(scaled) companies – tend to considerably adapt agile or adopt only certain
Similarly, don’t simply pivot from a bad idea but pivot to a components to suit their unique organizational structure and culture.
promising new idea based on insights gathered from your
previous attempts. Hold true to your overall strategic goals Agile is a powerful theory but requires much to go right in practice. For
example, everyone on the team must:
– a pivot should help redefine a workable solution but
shouldn’t swing you into a whole different problem space - deeply understand business goals and customer needs
or target customer set. These are strategic pivots requiring - be outspoken and ready to commit to regular deliverables
much more thoughtful analysis. - be in-sync; everyone knows what everyone else is working on
- embrace core values and see constructive conflict and collaboration
(including regular meetings) as a good use of time
Ø Accelerated Business Value – Iterative methods emphasize building - work with the utmost sense of urgency
small units of “potentially shippable” product with demonstrable - ensure all planning and update forums (meetings) are run well and
business value (functionality and quality). Delivering working code lead to desired outcomes
each cycle forces the team to think in terms of the business value
- be open to feedback and ready to openly track their pace of work

Getting all those in to work seamlessly is a challenge. To compensate, Structure of Agile/SCRUM

Hybrid Waterfall/Agile methodologies are commonly used to introduce
more process; more checks and balances. Companies can to do some In 2001 a group of developers met to discuss why a great many software
upfront planning, dictate some scope, manage scarce resources, establish projects seemed to fail – they formed the Agile Alliance and developed an
target dates, and develop a release plan across multiple teams.
Agile manifesto and twelve accompanying principles as a framework to re-

think how modern product development can be performed.
They may use modified phases such as Discovery (requirements and

prototyping), Planning, Implementation, and Evolution as an overall Standard software development approaches had become burdened with
Waterfall framework. Agile is integrated into the implementation phase by: excessive planning and implementation steps, the production of
1. breaking monolithic overall requirements into smaller deliverables to deliverables (documents, plans) that added no customer value, and
be completed iteratively excessive hand-offs between many functional teams. Furthermore, as the
2. integrating UX and engineering design, and QA testing, in each pace of market and technology change accelerated, the need for
iteration rather than as separate phases continuous validation and quick adaptation to new realities became
essential.
Consider the rest of this chapter in light that you may not be in a pure Agile
environment. It may even be unrecognizable. Nonetheless, each of the The Agile Manifesto emphasizes collaboration, frequent delivery of
best practices provide insights into how you, as a Product Manager, can be business and customer value, reduction in wasteful activities, and flexibility
most effective in supporting your Development teams. to change. It is comprised of only four statements:

- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan

They were careful to note that the secondary concerns (on the right) were
still important, but the primary concerns (left) were more critical to
success. The authors understood that process, documentation,
requirements gathering, and planning were still essential to success. Each
had become an integral part of modern software development because
each served an important purpose in defining, managing, and
communicating delivery. However, they had become over-burdensome,
busy work, and a crutch replacing collaboration and flexibility. Nothing in
the Agile manifesto suggests they ought to be abandoned entirely – rather
they can be made light-weight and adaptable, to support the successful
delivery of valuable product to customers as efficiently and quickly as
possible.


From a Product Manager’s point of view, each manifesto statement has

critical implications for how you might consider approaching your role:

ü No “throwing over-the-wall” – you will operate as part of the team,
collaborating frequently with designers and developers. You will not
simply deliver requirements, and ask for a plan and timeline.

ü Outcomes not process oriented – you will trust your team to make
commitments and figure out the best way to achieve the goals.
Working, quality software is what counts – with the smallest possible
overhead necessary for supporting the team and monitoring progress.
And when things don’t get where you’d hoped, encourage them to
focus on constructive self-reflection and continuous improvement, not
blame or excuses.

ü No “but that’s what you asked for” – you will seek frequent feedback
from customers and stakeholders by showing them partially working
product. You will not hold them to a set of upfront requirements. Nor
will you become defensive if the customer is criticizing the very
functionality they were advocating for, or even contradicting
themselves after they see it in action.

ü Embrace justified change – you will be accepting of changes driven by Development Process Tip #2 for PMs
customer feedback, technical challenges, and business re-prioritization
(which can occur at any time in a fast-paced organization). You will be Do not let the use of Agile become an excuse to abandon
responsible to surface the implications of different trade-offs, all planning, use of tools, documentation, upfront
understand options, drive decisions, and communicate the outcomes requirements gathering, or establishing commitments and
across customers, stakeholders, and the team. In particular, ensure timelines. Agile simply values flexibility and collaboration
implications on timeline are understood (no holding engineering’s feet over these, not the elimination of them.
to the fire for timelines built on previous scope assumptions).

SCRUM is one of the more popular Agile methodologies – and its simple,
but rigid structure, allows it to be applied readily. Yet, it takes much
practice to master. opposed to a "traditional, sequential approach”. Coining a phrase from
rugby, SCRUM is where the team tries to advance the ball as a unit, passing
It was first introduced by Japanese experts in 1986 (New Product the ball back and forth as needed. The term caught on and was formalized
Development Game) as "a flexible, holistic product development strategy” throughout the 90’s and early 2000’s by software and Web development
where a development team works as a unit to reach a common goal" as companies. It has since evolved, as stated by the SCRUM Alliance, into:

“a simple yet incredibly powerful set of principles and practices that help
teams deliver products in short cycles, enabling fast feedback, continual
improvement, and rapid adaptation to change.” The Twelve Principles of Agile

1. Customer satisfaction by early and continuous delivery of valuable software
Key attributes of SCRUM include: 2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
- a small, cross-functional team (usually 5-9 people). Each team member
4. Close, daily cooperation between business people and developers
plays one of three roles.
5. Projects are built around motivated individuals, who should be trusted
- a self-organizing, self-accountable team without a direct manager. 6. Face-to-face conversation is the best form of communication (co-location)
While team members do still have a “boss” in a SCRUM environment, 7. Working software is the principal measure of progress
s/he doesn’t dictate what or how they work. Rather the team is 8. Sustainable development, able to maintain a constant pace
charged with deciding on commitments and approach, and self-assess 9. Continuous attention to technical excellence and good design
and report on their own success. 10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing
- team members commit to live by five core values.
teams
- one short-term goal is completed within an iteration, called a Sprint. 12. Regularly, the team reflects on how to become more effective, and adjusts
accordingly
- sprints contain four planning, check-in, and retrospective ceremonies.

- planning and tracking are supported by using two lightweight artifacts
– the Sprint backlog and burndown.

The typical length of a Sprint varies by organization, project complexity,
and the type of product being worked on. A range of 1-4 weeks is usual, Development Process Tip #3 for PMs
with 2 weeks standard. Smaller iterations start having too much overhead
and longer iterations create wait-times too long between review of Some developers might be uncomfortable with the
“working code”. requirements ambiguity inherent in Agile. They may view
new details or changes as an inadequacy of the PM’s ability
5-4-3-2-1 SCRUM to “lock-down” scope, to understand customer needs, or

just changing your mind on a whim. They may become

5 values vocal complainers, resist or lose respect for you. It is critical
4 ceremonies you, as PM, provide context for all changes to anchor them
the underlying rationale and to remind your team you are

3 roles in a constant learning and validation cycle.
2 lightweight artifacts

1 short-term goal


Five SCRUM Values

ü Committing to something without all the details or certainty you
To make small teams effective, SCRUM encourages members to embrace know how to get there in the time available
five powerful teamwork values. Product Managers should endeavor to ü Willingness to deliver bad news when necessary
highlight these values and sample behaviors within their development
teams and, naturally, lead by example.
Ø Focus – work toward the Sprint goal. Because the team only focuses
on a few things at a time, they produce excellent work and deliver
value sooner.

Sample focus behaviors
ü Pulling in work only from the backlog. Allowing only pre-agreed
interruptions (company meetings, emails, P1 emergencies).
ü Ability for anyone in the team to restate the Sprint goal at any
time, and explain how their work adds business value
ü Pushing back and alerting your team if your manager or others
task you with other work (even if it is deemed urgent)
ü Not letting yourself get distracted or taking a more complicated
route because you find something cool
ü Constant evaluation of how to work more efficiently and
eliminate waste

Ø Commitment – autonomously, collectively and universally commit to a
goal and scope at the start of the Sprint, and strive to achieve it.

Ø Courage – work through conflict and challenges together, so that the Sample commitment behaviors
team can achieve the right goals. ü Signing up for a full Sprint’s work, giving believable (not padded)
estimates, and pushing yourself out of your comfort zone
Sample courage behaviors
ü Believing in the goal, and feeling it is both audacious yet
ü Willingness to disagree and accepting if you are wrong obtainable (neither too much a stretch nor easily mailed-in)
ü Get with the program, after you have said your piece, even if the ü If the goal is at risk, working harder and more collaboratively (a
decision isn’t what you’d advocated (don’t continue pushing back)
sense of urgency, some peer-pressure)
ü Stretching yourself by learning new skills or going beyond your ü Feeling “bad” and seeking self-improvement if you don’t hit the
role description, if it helps get the team’s tasks done goal or complete committed scope (no “meh” shoulder shrugs)

ü Honestly meeting all standards for quality, acceptance criteria,

and documentation, in addition to readily visible functionality
War story – Openness when you need help

Ø Respect – trust and believe each other are technically capable, and to I was overseeing a client engineering team charged with creating
work with good intent (no blame, no politics, no judging, no onboarding tools for new customers.
undermining).
One Sprint I noticed that the tasks in the backlog didn’t seem to
Sample respect behaviors be being marked as complete at the same rate I had seen in the
ü Listen to each other, and help others when they struggle with past. I was concerned we weren’t making enough progress
something – ask if you notice someone needs help towards the Sprint goal – a team commitment had been
communicated to a key customer who was scheduled to come
ü Embrace decisions made by the accountable role (e.g. Product
and sit in on our Sprint demo.
Manager decides priorities, Engineering decides technology).

ü Operate as equals regardless of seniority (no exercising authority At the daily stand-up meeting no team member expressed any
or power over others) blockers – so I kept quiet and trusted that the team were on top
ü Drop the ego and heroism (succeed or fail as a team regardless of of it. After all, as Product Manager, the last thing I should be
individual contribution) doing is second guessing the development team and checking up
ü Avoid defensiveness, taking things personally, or reacting on them all the time.
emotionally
Unfortunately, a few days later one of the engineers admitted he
had been trying to solve a content import failure for several
Ø Openness – transparency with all stakeholders and each other about days… well in excess of the expected amount of effort we had
the status, timeliness and quality of the work. estimated coming into the Sprint. Each time he thought he’d
solved the problem, but then something else would come up. He
Sample openness behaviors got so enthralled and caught-up in overcoming the challenge, by
the time he told the team about it he’d already spent three days
ü Immediately highlight when you have challenges or difficulties
on the task.
that are slowing you down (unafraid to ask for help)

ü Avoid communicating Stakeholders with spin, skipping over Turned out one of the other engineers knew exactly what the
inconvenient details, or leading with justifications or excuses issue might be and within a few hours, the problem had been
ü Explaining trade-offs and decisions, and embracing critique and solved through a partnership between the two engineers.
feedback on the work product
ü Willingness to report publically on tracking metrics such as team Had he spoken up earlier, we’d have been able to help him. But
velocity and burn-down charts we were now unable to hit our goal.
ü Sharing perspective on what in the process is working and what
needs improvement, and seeking and adopting feedback

Three SCRUM Roles

There are only three roles in a SCRUM team:

Ø Product Owner – in most teams this role is assumed by the Product
Manager. The PO manages the requirements backlog and makes
themselves proactively available to the team during the Sprint to
quickly turn-around answers to questions or make decisions.

Specifically, the Product Owner (PO):
- owns the overall direction of the product and communicates the
vision and business context. (See Chapter 15 – Leading Through
Influence for the importance of, and techniques for, setting
context)
- establishes a Sprint goal in collaboration with the team
- defines and prioritizes the “what” (user stories) before the start of
the Sprint (See Chapter 11 – Mastering Product Requirements)

- clarifies requirements and provides feedback throughout the

Sprint
- works to remove impediments slowing the teams progress. These
- sets the definition of “done” for each user story (before the start
can range from organization issues, to dependencies or blockers
of the Sprint) and signs off when these are satisfactorily met at
(such as waiting on other people to complete tasks), problems
the end of the Sprint
with the development environment… anything slowing the team.

Ø SCRUM Master – this maybe the least understood and most difficult - as a senior, respected leader they are well placed to motivate
role in an Agile team. The SCRUM master oversees the process and others and provide (or secure) coaching or training
ensure the team remains unblocked and focused. In some - balances the Product Owner by protecting the team from
organizations, they’ll have a dedicated SCRUM master or Project overcommitting, driving trade-off discussions, and ensuring
Manager (shared between teams), but so to a respected, senior lead requirements are sufficiently clarified
engineer double-hat as SCRUM Master.
The SCRUM Master might not directly lead each of these efforts –
Specifically, the SCRUM Master (SM): often a Product Owner or Engineering Manager might be delegated or
- facilitates the process, ensuring the SCRUM ceremonies achieve assigned to tackle issues. But the SCRUM Master is responsible to
their goals and the team is working towards the right priorities ensure these are followed-up and addressed.

- tracks and reports progress (regularly checking in on team
A Product Owner must never double-hat as a SCRUM Master for two
members and communicating issues where necessary)
primary reasons:

1. Conflict of interest – PO’s incentives are to optimize for maximum - actively participate in all ceremonies, proactively communicating
business value delivery. Generally, they encourage teams to be issues and ideas for addressing them. They get up in front of
aggressive on commitments and have strong points of view about stakeholders to present working code at the demo (not the PO).
how to implement feature specifics. There is nothing inherently
wrong with that, but a SCRUM Master’s role is to protect the
team even from an assertive PO. When POs attempt to perform
War story – Product Owners Shouldn’t Drive Engineering
both roles simultaneously they may stream-roll a team into
agreeing to a plan they don’t believe in – disempowering and
demotivating them. It is hard to effectively negotiate with oneself. I sat in on a Sprint Planning Meeting recently with a Junior
Product Manager. The PM led the meeting, immediately jumping
2. Strategy vs. Execution – the PO owns the customer needs, future into a walk-through of his user stories. Pausing only briefly – no
Sprint goals, and prioritization of user stories. They must think comments or questions came up from anyone. He then led them
ahead of the team to plan, prepare and validate future work. If through the estimation process – each time they bid a number
they get too caught up in the day-to-day management they don’t he’d push them to select the lowest number as their estimate or
spend enough time with customers or stakeholders, nor prepare challenge them. Everyone in the room except for him was silent
for future Sprints with enough rigor. When the next Sprint arrives, almost the whole meeting.
they are left scrambling to define sufficient work for the team to
complete or (worse) provide only vaguely thought-through After a while, realizing it didn’t make any difference, the team
requirements. became disengaged and resigned to defaulting their bids to the
same estimate of “5” for every story regardless of actual
complexity.
Ø Team – the collection of cross-functional professionals assigned to
work on the product. The team may include User Experience, The PO, sensing the disengagement and feeling frustrated said:
Engineers (“full-stack”, “front-end”, “back-end”), Data Scientists, “Look, I don’t like this either but the CEO is telling us to deliver
Quality Assurance, and anyone charged with delivering any substantial this”. They finished the meeting and trudged out of the room.
part of the scope.
The mistake? Well many! Rather than supporting a team of self-
Specifically, the Team: organizing, motivated individuals, the PO was driving the team –
acting as both SCRUM Master and PO – seeking to get the team
- commits to Sprint scope, by pulling priorities from the backlog, on the hook for as much as he could.
breaking-down stories into tasks, and estimating effort. They
decide when they have committed to enough for the next Sprint. The team were clearly disempowered. They hadn’t been provided
- seeks requirement clarification from the Product Owner context for why they were being asked to do what they were
- collaborate with each other to decide on the best approach to being asked to do. And he made the most fatal mistake of all – he
deliver on the requirements (balancing design, engineering and used the positional power of the CEO to get them to fall into line.
QA needs)
Fortunately, he responded well to coaching.
- completes the work and validates it passes acceptance criteria. If
necessary they assist other team members to meet Sprint goals.


Four SCRUM Ceremonies

SCRUM calls its meetings, ceremonies – and for good reason. Unlike many
meetings, ceremonies are designed to keep the team energized, focused
and celebrating success together. They are also meant to replace the
countless planning and endless requirement elaboration meetings that
traditional methodologies seem to be saddled with. The team must be
committed to running their ceremonies on-time, efficiently, and focused
on the intended outcome.

The overall SCRUM process integrates the four ceremonies together to
plan, implement and review an entire iterative cycle. Each are described in
more detail below, but for a quick overview:

Ø Sprint Planning – establish an overall short-term goal and commit to a
set of known scope and tasks for the next Sprint. Sprint Planning is the
almost the only time scope can be added into a Sprint – the two
exceptions are discussed later.

Ø Daily SCRUM – each team member updates what they have achieved As Product Manager, you likely don’t have direct control over your
since last daily SCRUM, what they are focusing on now, and any organization’s schedule. If you can influence it, I recommend a 2-week
blockers to their progress. It is meant to be short – and therefore is Sprint cycle starting with Sprint Planning on the Monday of the first week.
sometimes called a Stand-up because no-one is allowed to sit down Hold it mid-morning or first-thing in the afternoon. This allows the team to
and get too comfortable. approach the next Sprint fresh after a weekend break, with a few hours to
settle and complete final preparation. Don’t start the ceremony too late in
Ø Sprint Review – game time; the team’s work is on show. A demo the day either – give yourself time to finalize scope and plan (including
showcases work done during the Sprint and stakeholders provide chasing down last minute clarifications) by the end of the day.
feedback and further business context. User Stories that satisfy the
acceptance criteria are declared done and closed. Stand-up is best held first thing every day. Don’t skip the day after Sprint
Planning, since this is your first chance to ensure the team has started
Ø Sprint Retrospective – the team comes together to honestly and strong and is aligned. Help drive a culture that all team members must be
openly discuss their process and collaboration; both successes and on-time and attend in-person (unless they are remote located, and then
improvement opportunities. They decide on a plan to implement via video conference). Everyone stands.
enhancements immediately for the next Sprint.
Sprint Review needs to be timed with when you can get stakeholders to
And then the cycle starts again! attend. Ideally it is either Thursday afternoon or Friday morning of the

second week. This maximizes time in sprint while giving the team a little stories. Without it, the sprint is just a collection of loosely affiliated
time after the review to consolidate feedback, close stories, make last user stories seemingly unconnected to building value for the business.
minute tweaks, and some free time to work on minor projects. Leave some Do not overthink your goal and have a back-up ready in case.
space at the end for everyone to mentally prepare for the following sprint,
most importantly to seek clarification of incoming scope. Attributes of Good Sprint Goals
- business value focused – motivational for the team
Sprint Retrospective is best held soon or immediately after the Review.
- short-term and achievable within the sprint. If it potentially spans
Friday afternoon over a drink isn’t uncommon.
multiple sprints, break the goal down further.

- provide a theme for stakeholders to contextualize the demo
We will discuss in more detail how each ceremony works, and the specific - do not need to encapsulate all the sprint’s user stories, just
role of the Product Owner in each (along with pitfalls). enough to focus the team on a piece of discrete business value

- not the same thing as your overall product vision, EPIC, OKRs,
1. Sprint Planning “increase revenue”, or any other longer term business metric

It is the Product Owner’s responsibility to perform the following tasks prior - not completely tactical (e.g. “complete stories 1-5 by end of
to Sprint Planning. At least a thorough draft is required, with finalization sprint”)
occurring during and immediately after planning. - appropriate for the lifecycle of your project (early-on emphasize
discovery, learning, risk mitigation; and later-on polish,
ü Backlog Grooming – have a fully groomed Product Backlog with all the optimization, clean-up)
highest priority items at the top. The PO must also have broken User
Stories into smaller stories that seem small enough to fit into a single
iteration. It is common for some stories to be further broken down Example Sprint Goals
during Sprint Planning – but best to preempt this if possible. (See
Chapter 11 – Mastering Product Requirements for more on backlog Ø Create a high-fidelity prototype of the XXX feature to test the
grooming and techniques for breaking down stories). UX (Discovery)
Ø Deliver the basic functionality or flow for XXX (Feature
ü Scope Clarification – the team is responsible for understanding scope Delivery)
and asking clarifying questions of the PO before the planning meeting, Ø Explore 3rd party solutions to outsource subscription platform
(Mitigate Key Risk)
so critical conversations have already started. Encourage them to
Ø Create the baseline data and API platform to support the
initiate the process over email or in a Pre-Planning discussion so you
product (Foundational or Architectural)
can walk into Sprint Planning with answers and data. Ideally, user Ø Address the top 10 bugs/usability/stability issues
stories have conversation details and acceptance criteria drafted. (”Hardening”)
These can be finalized during Sprint Planning, Ø Rewrite XXX functionality for performance (Technical Debt
Removal)
ü Goal Preparation – the Sprint goal or theme is a discrete piece of Ø Test pricing models/user engagement/customer conversion to
business value that the PO desires, but is not assured, to achieve increase outcomes (Business Optimization)
within the sprint – which encapsulates most of the highest priority

It is essential the PO is not driving Sprint Planning, because the Team must
have a sense of ownership and control over the commitments they are
making. The SCRUM Master or any other member of the team is preferred
(try rotating around the team, sprint-to-sprint).

During Sprint Planning, it is the Product Owner’s responsibility to:

ü Goal Setting – Introduce the goal or theme, and provide context for
why this a priority at this point. Some data and rationale (perhaps a
few slides) is essential – ideally customer or business driven. You can
have multiple goal candidates for the team to consider and weigh-in
on which tackle, but ensure only one is agreed to before moving on.

ü Support the Sprint Backlog Buildout – open your Product Backlog and
bring up the top-priority story. Describe it and ask for further
clarifications. The Team is then responsible for breaking out
implementation tasks, and estimation (see later in the chapter). Once
estimated, move on to the next story and continue the process. This
continues until the Team feels the sprint is fully committed.

A common problem with some junior teams is they under-estimate
the work to fully test and validate each user story. You should see Development Process Tip #4 for PMs
testing items reflected in the tasks. If not, ask the team whether they
have included sufficient time to write unit tests, validate, and de-bug Especially early in a project’s life, scope can be unclear.
their code so it will pass the acceptance criteria. Sprint Planning meetings risk extending for many hours to

properly clarify all requirements, add necessary details, and
If a story seems to be have too many outstanding clarifications to
make estimates. Sometimes clarification questions cannot
address or team expresses concerns, skip it and come back to it later
in the meeting; or reconsider it for next sprint. Just because stories are be answered during planning, resulting in an aborted Sprint
in a set priority in the backlog does not mean the team must do them Planning – setting back your Sprint by a few days.
in a strict order.
If necessary, schedule a “pre-planning” meeting a day or
two before Sprint Planning to split clarification and
ü Take Copious Notes – so much information is shared during the Sprint. commitment into two shorter sessions. This gives the PO
Always capture all the conversation, decisions, and outstanding issues time to gather information to answer questions.
and write in the appropriate place within the user story in the product
backlog. If you observe team members making notes outside of the

backlog ask them to enter them into the backlog instead or send to
you to incorporate.

Finally, create an action plan and immediately follow-up any
outstanding steps. Try to close these out on Sprint Planning day so as
not to delay the start of the sprint or to leave commitments
conditional on some critical piece of information.

ü Respect Commitments – PO’s are in a tough spot. They are
accountable for shipping valuable product to customers, yet rely on
the development team to build it. Nonetheless, if Product Owners try
to push too hard on teams to commit to more they are comfortable,
then morale drops and sense of ownership is lost. You may well find
less being achieved, not more. Further, never shame a team for
missing commitment unless you want them to low-ball you next time.

The PO should, though, encourage the team out of their comfort zone;
to live the courage value and commit to something that they aren’t
sure how to or whether they can get there. In a high-functioning team,
everyone understands the desire to deliver more and take greater
risks. They’re working hard and wanting to please you – and will
endeavor to take on more and will push-back when enough is enough.

Scope should never be added once a sprint is started, even if it 2. Sprint/Story Abort – if a goal or key user story is no longer needed due
appears the team has capacity or the new scope is small. This requires to unexpected changing business needs, stories can be abandoned by
discipline. The advantage of not adding scope include focus, less the PO. At the team’s discretion, they can replace with new stories.
context-switching, accurate tracking, ensuring quality, and showing This only works if this event occurs early in the sprint, and is not
respect for the SCRUM process. Once a back-door is opened, this desirable as it can mess up tracking and the sprint cadence.
leaves its open for stakeholders to do the same.
Everything else can wait for the next Sprint to be addressed – at worse,
There are two exceptions: this means new scope waits just one iteration before it can be worked on.

1. Team achieves Sprint goals early – at the team’s option, they can In general, disruptions (bugs, urgent issues, overheads like meetings and
pull in stories from the backlog mid-sprint. This must only occur email, and assistance provided to other teams in the organization) are not
once all committed stories are complete. If some committed considered scope. These do however, obviously, use time and as a result
stories are still open, it is better for all the other team members to may impact the number of user stories the team can complete. As we shall
help on these rather than add more work (called “swarming”). see shortly, teams should factor in these into their overall sprint velocity.

2. Daily SCRUM (Stand-up)

War story – My Team is Too Conservative

The daily SCRUM is a place where yesterday’s accomplishments and daily
Product Managers frequently expressed a frustration they have
goals are affirmed. Ideally it is held in the same place each day, so
with Sprint Planning. Their responsibility is delivering business
everyone “gets in the routine”. Standing up is customary so no-one gets
value to the organizations as quickly as possible at the required
too comfortable and turns it into an hour-long meeting. The SM usually
level of usability and technical quality. It is often they that feel
runs the meeting – but anyone other than the PO can.
the heat when delivery is, or is perceived to be, too slow.

The format is simple – each member of the SCRUM team has a turn at
In SCRUM though, PO’s are not in a position to directly make
answering three questions:
engineering work faster or commit to more. However, I have

found the following techniques to be effective in accelerating
1. What did I work on/accomplish yesterday?
throughput. Try some and see what works for you…
2. What will I work on/accomplish today?
- Encourage the team to increase each week’s commitment by 3. What impediments are in my way?
10% more over their average. Make this a “stretch” goal
which complements the official sprint commitment. Team members are expected to be transparent and share good and bad
news. If, for some reason, a member of the team has not been able to
- Have a policy to prepare two-three extra stories per Sprint, complete something they committed to, or is stuck in any way, it is an
outside of the official committed scope, but ready-to-go at imperative they volunteer the information (as opposed to waiting to be
the top of the backlog. The team can bring these into the asked). If a team member isn’t forthcoming for some reason, the SCRUM
sprint only after all other stories are complete. Master is expected to probe to ensure the three questions are asked of
and answered by everyone.
- When the team declares the sprint fully committed, have
each write down their level of comfort with the The Sprint Backlog and Burndown should be on a board or screen showing
commitments so far made (1-10, where 1 is highly work-in-progress (so no status update is overlooked) and as a reminder of
comfortable and 10 is highly uncomfortable). If the average tasks that are complicated yet haven’t been started yet.
is 7 or below, encourage the team to push out of their
comfort zone. The daily SCRUM is not a place to resolve issues, or ask or answer
questions other than these three. If impediments are identified, team
- Go through priorities lower in the backlog and find a couple members (under the guidance of the SCRUM Master) agree on who will be
of “easy stories” to knock off. Ask to add to the sprint. responsible for follow-up after the ceremony. Usually this is a smaller
subset of the team and, if a serious blocker, immediately. While the
- Observe blockers surfaced in standups and retrospective SCRUM Master is overall responsible for ensuring the impediments are
outcomes. Identify underlying inefficiencies and negotiate addressed, the PO should offer to help in any way.
with the team time to address them in return for greater
commitments.


The PO’s primary responsibility in Standups is to observe and get a sense of

the patterns emerging – which you take “offline” to explore further with
the SM or team members. Good questions to ask yourself:
- Is the Sprint Burndown moving at a pace where I can see the end in
sight?
- Are team members marking completed user stores as “done” or “code
complete” and therefore is the Sprint Burndown an accurate portrayal
of progress? (note: stories can be marked done but not closed until
acceptance criteria validated as passed)
- Is what was promised yesterday what was worked on yesterday?
- Is what is promised today in the Sprint backlog and aligned with the
Sprint goals?
- Am I hearing the same tasks as priorities come up again and again over
multiple days? Does that suggest something is stuck?
- Are any of impediments related to requirements clarity? How can I
assist? How can I do better next time?
- Are impediments addressed within a day or so? (This should be easy. If
the problem is still being talked about at the next stand-up, that
indicates there may be a larger issue.)
Example Impediments
- Are there any potential issues not being raised? (as indicated by body
language or a quiet team member) Ø My ____ broke and I need a new one today
- Do I see a sense of urgency and engagement? What can I do to Ø I still haven't got the software I ordered a month ago
Ø I need help debugging a problem with ______
encourage and motivate?
Ø I'm struggling to learn ______ and would like to pair with
someone on it
Anyone can, and is encouraged, to attend Daily SCRUM as it is a wonderful Ø I expected ______ to take two hours, but I’m still working
information dissemination opportunity (better than status emails or through it
meetings). However, everyone must abide by the cardinal rule… under no Ø I can't get the vendor's tech support group to call me back
circumstance should stakeholders ask questions, request to see work- Ø Our new contractor can't start because no one is here to sign
output, or provide input during Stand-up. If this happens, the team should her contract
Ø I can't get the ____ group to give me any time and I need to
ask the stakeholder to speak to the SCRUM Master or PO after the meeting
meet with them
or wait until the Sprint Review for an opportunity to provide feedback. Ø The department VP has asked me to work on something else
"for a day or two.”

Thanks to www.mountaingoatsoftware.com


3. Sprint Review (Demo)

The Sprint Review occurs on the last day of the sprint. As Stakeholders Pigs and Chickens
may attend more than one review for multiple SCRUM teams, reviews
might need to be staggered over a whole day. Anyone with “clearance” When you make bacon and eggs, the chicken contributes – but
can attend, so long as they have an interest in what the team is working on the pig is committed. Get the joke?
and willing to provide input. Don’t forget that internal stakeholders are not
customers. Be prepared to be the voice of the customer if you think the This is an important distinction for how Stakeholders (Chickens)
discussion isn’t representative of their interests. and Agile teams (Pigs) are expected to interact. Chickens are not
welcome at Sprint Planning or Retrospective, where they can be
It is “good form” for the PO to allow the team to shine – individual team disruptive or affect the team dynamics during sensitive
members demo their own work. It helps the team be more visible, discussions.
motivated, and accountable. Even though not all team members are
polished presenters, it is more valuable to work through that awkwardness At Stand-up Chickens are welcome to observe, but stay silent and
than have one person dominating the limelight. let the Pigs speak. They are also not supposed to request status
updates, demos, or ask for changes midway through a Sprint –
Another critical rule – no slideware. Working product only. This includes unless the Pigs request it. A good PO or SM will, however,
not hacking a product to achieve the illusion it works. If a User Story has proactively send out updates to keep Chickens in the loop.
not met Acceptance Criteria, do not let the team pretend it is done. Save it
for next demo. It is at Sprint Review where Chickens are encouraged to provide
business context and product feedback, negative or positive. The
For Sprint Review, it is the shared PO/SM responsibility to: Product Owner is responsible for considering (but not necessarily
committing on the spot to) addressing their feedback.
ü Secure Buy-in – if certain attendees are prone to de-rail or bring up
unrelated issues (such as revisiting prioritization decisions or business
goals); or if you know that the product demo won’t be as polished or
complete as a specific stakeholder might expect, seek buy-in ahead of
time. (See Chapter 15 – Leading Through Influence.) Remind them of
the purpose of the Sprint Review, give them a preview of what is to
come, and ask them to bring up concerns with your directly now
rather than then when it may deflate a hard-working team.

ü Schedule and Validate Demos – assign each user story a presenter
and ask them to prepare (script) their demo. Ensure the product demo
is working completely – these tend to be on development servers
which might not work according to plan in the review. Time everything
out to fit into no more than 1 hour. Give feedback or suggest a dry-run
for any team members new to this.

ü Structure and Open the Review Meeting – bring up the Sprint Backlog
with all the “done” stories, but not yet “closed”. Remind all present of
the purpose of a Sprint Review and (if necessary) what they can expect
and how you would like Stakeholders to engage with you and the
team. Introduce the Sprint goal that was set at Sprint Planning, and
highlight the committed User Stories.

Step back, and let the team take you through each story in turn. Each
introduces the User Story (read it out), then each step in the flow. It is
fine if the user interface isn’t polished, particularly early on. Have
them talk through what a rough design, prototype, or command-line
code is doing so Stakeholders can follow along.

ü Read the Room – invite stakeholder feedback by asking them
questions. Avoid getting defensive or explaining away limitations.
Stakeholders can sometimes be overly critical. Probe for
understanding – if you get feedback make sure you understand why.
The underlying business context shared among all the team is much
more valuable than reactions to a feature. It helps everyone make
better decisions in future. If something comes up that isn’t relevant,
listen for a bit to confirm your suspicions and then bat it away with Specifically, address these questions:
“Great question. Can you and I take that offline?” – and follow up - What are the overall impressions of the stakeholders? Positive
after. and concerns?

- Are you on-track to a suitable overall release timeline? (Bring up
If a team member skips over important context and Stakeholders
your overall Product Burndown chart if helpful.)
appear lost, ask the presenter in the form of a question (resist the
urge to state it for them). For example, “When you clicked on submit, - What additional business context, priorities come to mind?
where did the data go and what happens next?”. - Does the team have any “asks” of Stakeholders? (support,
resources, information)
If something goes wrong in demo, simply acknowledge it, make a
- What are next steps? Make commitments to follow-ups.
note, and keep moving on.

If helpful, recruit a stakeholder before the review to send a message

or reiterate a point you have been making. This is particularly useful if
ü Summarize Overall – open-up the floor to discuss how things are
your team needs to hear from someone other than you (for example,
going overall.
if the team appears to lack a sense of urgency).


ü Celebrate – if things are going well, “pre-wire” stakeholders to

emphasize the importance of the work the team is doing and the
impact to customers and the business. Have them call out names and
specific achievements. It is a huge morale boost to know that senior
stakeholders value the work that is being done.

Have an official moment when successfully completed stories and
formally closed and the Sprint declared over. It is satisfying to see
work move out of the queue.

Ø Follow-up – immediately after the meeting, add new stories with what
you have learned and start grooming the backlog for the next Sprint. It
starts sooner than you think.

A short note to everyone who attended the demo summarizing what
you heard and to surface issues that may not have been shared is
recommended. It is common in a large meeting, particularly with
people present over all levels of seniority, for not every issue to have
been raised.
Sometime teams get out of the office and go somewhere fun, to warm up
and break down communication barriers. The meeting is best started with
4. Sprint Retrospective revisiting the previous retrospective’s outcomes. Given the issues from the
last retrospective: what worked and what didn’t. If the team did much
Agile enables the opportunity to inspect, learn, and adapt both product better and the improvement became a new good habit, then celebrate. If it
and process. There is always room for improvement. The Sprint didn’t, discuss why and resolve to tackle it again next Sprint. (Chances are
Retrospective provides a safe space for the team to share the recent if it was the highest priority issue last time, it probably still is.)
experience while it is still fresh in the mind.
Then the team discusses what went well and what didn’t go well in the
The goal is for the team to constructively identify actionable improvements Sprint just completed. These should be captured on a whiteboard or
and leave the room feeling good about themselves. They avoid getting shared document. Themes tend to come up again later.
personal, and stick to the facts.
Unless the team is very high-functioning, addressing one (at most two)
What happens in retrospective stays in retrospective. Unlike the Review, actionable and high impact issues each time is all that is required. Simply
this is a closed meeting. No Chickens allowed – only the SCRUM team. by sharing all other issues has improved communication and awareness.
Even the PO is optional or may attend only for a limited time, to provide an One or two committed next steps provides the team focus and something
opportunity for the core-team to speak freely without them in the room. they can all agree on to fix. These are integrated into subsequent sprint(s)
(Ask to be invited and leave it up to the team to decide.) until the new habits are adopted or no longer relevant.

Agile Estimation – Story Points and Velocity

The overall goal of Agile/SCRUM estimation is to establish a measure of the
throughput or “velocity” for the amount of work a team typically gets done
each Sprint, and to use it as a guide to future Sprint commitments. Not all
User Stories are equal – some are complex, taking several members of the
team to work concurrently for much of the Sprint to complete; while
others are relatively simple (say, a half-day for one developer). Therefore,
Agile attempts to score each story by a relative measure of complexity so
the team has a way to compare and avoid over or under-commitment.

Furthermore, by understanding the average amount of work completed in
each Sprint, and comparing that to the complete backlog of User Stories
for an entire project, it is possible to determine roughly when a project will
be completed. Because this data is based on actual throughput, and not a
theoretical project plan, these dates are believable .

The Product Owner usually does not participate in making estimates for
User Stories other than providing context for the team. The team
responsible for committing to the work should also be in control of
estimating the work involved. The Product Owner does use these
estimates to build up a rough plan for future Sprints – and determine likely
project completion dates.

In Waterfall, to build a project plan, a team of expert engineers, architects,
and project managers break out all requirements into engineering tasks.
The requires high levels of specific details (perhaps complete user interface
and system designs). These tasks were then evaluated in terms of person-
days and tasks sequenced to manage dependencies and resource conflicts.
Once all the pieces were broken out, they are put back together in a
schedule showing an expected delivery date. Building a Project Plan can be
a time intensive and a stressful exercise – and may not lead to predictable
dates.

Agile Estimation turns these techniques on their head – achieving both a
fast and efficient methodology using readily available data (the experience
of the team), and accuracy when tracked over enough sprints.


Ø Just-in-time/Time-boxed – other than high-level estimates provided at

the start of a project, detailed estimates are incrementally created
only at the start of each Sprint, when maximum information is
available about scope and the team is just about to start work.

Estimation occurs in the time allotted at Sprint Review. After
clarification and breaking a story down into tasks, the team converts
the t-shirt sized estimate into an estimate with higher-confidence.
That’s it! (See Chapter 11 – Mastering Product Requirements for more
on t-shirt sizing.)

Ø Collective “Gut-check” – even with loose requirements, on average,
the collective opinion of an experienced team has good enough
accuracy. And if there is a range of estimates and opinions within the
team, it gives them a chance to discuss why and debate whose
estimate is more reasonable. Perhaps one team member can see
complexity that others do not? Or they are making assumptions that
can be easily clarified by the PO? After discussion, the team usually
rallies behind a single estimate or agrees to take an average.

The key is to keep moving – overall, the margin of error for any one
user story is high, but collectively across the sprint they average out to and will be different across teams even in the same organization. (An
be surprisingly accurate. 8-point story might be a 13-point story to another team).

Never convert story points back into hours and don’t apply story
Ø Story Points – asking someone to estimate using hours is challenging points at the task-level. Keep it at the User Story level to avoid a false
and stressful. They start thinking about competing needs. Will I have sense of accuracy or micro-management.
time for meetings and email? Will I have to work over my lunch-break?
What if I’m asked to help someone else? If I’m running behind, will I
be expected to work extra hours to catch up? Hours leads to padded Ø Relative Sizing – rather than evaluate each user story in absolute
estimates and a tendency towards time micro-management. terms, Agile estimation uses relative sizing. As each story is estimated
the team will reflect on whether this new story is less, the same, or
Instead, Agile abstracts estimation to use “Story Points”, a number, more complex than other user stories already estimated for the sprint
usually between 1-20. A large story might receive 20 story points or comparable stories they have tackled in the past. If the task feels
indicating it is very risky and complicated – and perhaps needs to be more complex, higher effort, and/or riskier, then it deserves a higher
broken down further and clarified. An easy story might be 1 or 2 story number of Story Points than something that wasn’t as complex, time
points. What a story point is to a team is based purely on experience – intensive, or risky.

Ø Planning Poker – while nothing in SCRUM dictates the use of the

Fibonacci sequence in assigning Story Points, it is a terribly convenient
tool. It has a natural spread of “easy” to “difficult” using only 7
numbers – 1, 2, 3, 5, 8, 13, and 20. (To avoid a false sense of precision,
20 is used instead of 21). Planning Poker gamifies the process
encouraging all team members to participate in making estimates and
establishing commitment for the Sprint.

How to Play Planning Poker

1. Each team member downloads a Planning Poker application
on their phone, or buy a pack of cards made for the purpose
2. Cards are numbered: the higher an estimate is, the more
effort, uncertainty, and/or risk it contains
3. PO provides an overview of the user story and clarifies
questions
4. Each person, except PO, selects a card representing their
estimate – everyone shows their card simultaneously as to
not bias the others Velocity is calculated by the total number of Story Points completed in a
Sprint (not those initially committed). As each sprint is completed, the
5. If estimates are not the same, the SM calls on the team
velocity can be plotted on a chart to record trends, guide future planning,
members with the highest and lowest estimates to explain
and dissect issues.
their rationale

6. The team debates and after a short-time, bids again Ø Guide Planning – Velocity indicates to the team as to how many Story
7. If the team appears to be struggling either the SM or PO Points they can reliably commit to next Sprint. Typically, the moving
selects a story already with a bid and ask whether it is average of the last three Sprints is used. Recent experience is a better
more/less/the same complexity predictor of the immediate future, yet three is still enough data points
8. Repeat steps 4-6 until a consensus is reached (everyone to average out anomalies.
agrees on a bid and not strong-armed into it)
9. After a third failed attempt, take the average and move on When a new team starts working together or an existing team starts
work on new project, velocity will tend to jump around wildly – as they
10. Repeat with the next story underestimate or overestimate what they can get done in their first
few Sprints. Velocity tends to settle down quickly as the team
observes actual performance and adjusts expectations accordingly.


Ø Diagnosis of Issues – a consistent or slowly improving velocity is an Two Light-weight Artifacts (and Delivery Dates)
indicator of good health in the Sprint process. If velocity continues to
vary wildly beyond the initial sprints, or continually slows, then there These have already been briefly introduced.
is a good chance that one or more of the following four issues is
happening:
Ø Sprint Backlog – like the Product backlog, the Sprint backlog contains
- User Stories are not fleshed out with enough details and User Stories. It is created at the time of Sprint Planning and contain
clarifications, hence Story Point estimates are not grounded in an the committed stories for the Sprint. The team will take priority stories
understanding of the actual complexity. from the Product Backlog and bring them over into the Sprint Backlog,
- Team isn’t following the estimation process carefully enough; for where they break these down further into implementation tasks and
example “low-balling” estimates or not debating enough their assign more detailed estimates.
different point-of-view to reach consensus.
During the Sprint, stories move from a pending state, into work-in-
- A lack of testing, too many engineering short-cuts, or challenging
progress (when a team member starts work on it), then into a “done”
development environments is creating technical debt or
status (where the story is ready for acceptance criteria validation). A
overheads slowing development and troubleshooting.
story is closed only after acceptance criteria are passed.
- Unplanned work is entering the sprint after it starts. This is likely
to be interruptions or emergencies. The PO should ask for the
team to track time-spent on any substantial unplanned activity to
identify a plan of attack.

Product Owners must assess and help the team address these issues,
otherwise the project loses predictability.

Ø Performance and Comparability – Velocity is not comparable across
teams since Story Points have different meanings to each team.
Product Managers must never use Velocity to evaluate the
performance of a team relative to other teams. Neither must they set
a target in the hope the project will move faster. All Velocity does is
define and defend a sustainable pace for the team to work.

Velocity should slowly improve as teams learn to work better together
and solve underlying issues that are holding them back. The PO should
encourage the team to understand bottlenecks, especially those that
surface in Stand-ups and Retrospectives, and give the team time to
address them.


At the completion of a Sprint the whole Sprint backlog is closed and

new one open. Total “velocity” is calculated and reported. Incomplete
stories can usually be pulled back into the Product Backlog or moved
forward to the next Sprint.

Ø Burndown Chart – this tool measures progress toward the goals in
terms of total finished story points. Typically, a SCRUM team will have
one for the Sprint and one for the overall Release plan (all the planned
User Stories for the project being worked on).

Most backlog tools automatically track burn-down (or burn-up). It is
not unusual for burn-down to appear slow at the start of a Sprint and
accelerate toward the end. Teams thought need to be disciplined in
marking stories as done as soon as they have finished the work during
the Sprint. A common problem is that most stories remain in the open
state, even after they are done, and makes it appear as if the team is
not making much progress. Then later in the Sprint, suddenly the team
realizes and the stories are marked done all at once. This creates a lack
of progressive visibility and a chart that looks like a big step.

Release burndown charts show the collective delivery of multiple sprints
towards an overall shippable product, such as a series of Epics or your MVP To illustrate, in the conceptual diagram shown, you can see the first three
candidate. Release burndown charts provide greater visibility into “likely” sprints, only minimal scope is clear. The team is figuring out the extent of
launch dates based on the total number of sprints left (stories in a backlog what is required through experimentation, validation, and discussion.
/ pace at which stories are completed).
Around Sprint 3 the MVP candidate is much clearer, and the burn-down of
A precondition to a useful Release burndown chart is that you have stories starts in earnest. Velocity ebbs and flows, and new stories are still
captured all known scope in the backlog and provided a t-shirt size discovered even late into the Delivery phase. But as more Sprints are
estimate. (See “Product Backlog scaffolding” outlined in Chapter 11 – completed, a confidence builds around a range of dates (in this case
Mastering Product Requirements.) Furthermore, you will not be able to between 10-12 Sprints) that the product is likely to be of sufficient
talk dates for three Sprints, at least, until: completeness and quality to launch, given current scope and velocity.
- Discovery and Experimentation are well advanced, as these activities
will uncover additional scope that must be accounted for; and Done well, a release burn-down chart connects known scope and actual
team velocity to believable date estimates – allowing the Product Manager
- a baseline velocity is established, upon which you can size up the
to have data-driven conversations with Stakeholders about timelines and
entire backlog and roughly guess how many Sprints are likely needed if
potential trade-offs.
velocity continues at the same rate.


Common Agile Pitfalls

We have introduced several challenges with Agile so far in this chapter –
here are some additional common issues to keep an eye out for:

Ø Incrementalism – when working from iteration to iteration, teams can
lose sight of the overall vision or the motivation to try innovative
break-out ideas that might span many sprints. Initiatives tend to be
sized to fit within a sprint which leads to incrementalism, delivering
small optimizations around a local maximum. The bigger opportunity
may never be found.

Product Management Mitigation:
ü Ensure your team keeps sights on long-term goals by frequently
making these explicit
ü Develop your Vision and Roadmap (Chapter 4) as a balance to
short-term sprint goals

Ø Process Abandonment – as mentioned previously, teams must not
think following iterative methods gives them permission to skip
planning, architecture and design, documentation, estimation, and Ø Lack of Test-driven Development – unit tests should be built along
testing. Iterative methods simply make these steps more focused and with each increment. These unit tests then become part of an
effective, and must be integrated into each cycle. automated test suite to validate future sprints don’t break previously
completed user stories. The Sprint Review isn’t a real-world
Product Management Mitigation: environment, so teams must resist the temptation to cut corners to
ü Budget time within each User Story, and have team include get “working code” into a demo-ready state.
explicit tasks for architecture, documentation and testing
ü Allow for some Sprints to be entirely dedicated to non-feature
goals such as “Technical Discovery” (architecture preparation, ü Physically review the results of unit tests (ask to see them) and
proof-of-concepts), “Hardening” (tidying up already delivered only pass stories that you validate met the Acceptance Criteria
stories to make robust and stable), and “Technical Debt Removal” ü Negotiate with your team to rerun unit tests frequently on
(refactoring code) previously delivered code – have a report that shows what broke


Ø Organization Culture and Maturity – certain organizations struggle Ø Multi-location Teams – one of the twelve principles for Agile is that
with Agile because Management is expected to move away from teams ought to be collocated to maximize natural collaboration.
driving specific product or technology outcomes, setting immovable Unfortunately, in today’s modern technology environment this is
aggressive deadlines, interrupting teams mid-sprint, or overly frequent becoming an unreasonable expectation. Teams might be partially co-
check-ins for updates. Resources are costly and managers are located with some remote members. Or companies might augment
accountable to ensure they are delivering value. Early on, adaptive their teams with outsourced developers who are used to receiving
development methods have difficulty describing exactly what the detailed requirement documents.
product will look like and what when it will be delivered.
The tyranny of distance quickly kicks in – time zone differences,
Compounding these issues, many Agile teams are in the process of language differences, work-styles, lack of face-to-face time that builds
maturing and haven’t mastered reliable communication, velocity, or inherent trust, and level of comfort with conflict all undermine the
predictability. Some team members see ceremonies and other process effectiveness of Agile. Extra structure and more deliberate
as getting in the way of writing code. Particularly for SCRUM Masters, communication is required to compensate.
it requires natural leaders with strong communication skills in the
team to step forward, which you may not have available in spades in Product Management Mitigation:
your engineering team. The self-organizing nature of teams requires ü Explicitly agree overlapping work times, communication channels,
flexibility to change, willingness to work in ambiguity (e.g. making and how issues are escalated (with two-way response times)
estimates) and participate in defining the product (e.g. Isn’t the PM’s
ü Set up video conference links and ensure full-participation in all
job to tell me what to build?). This can be a stretch for many.
ceremonies

Management rightly can’t be expected to step completely back. But ü If possible, assign work in such a way that remote and in-office
neither does Agile need to conflict with management insight and personnel work on independent tasks (e.g. different stories)
control.

Product Management Mitigation: Ø “SCRUMer-Falls” – SCRUM is not intended to be small, sequential
ü Own communication with Stakeholders and ask them to work Waterfall processes compressed into a few week where each cycle has
through you to address scope, timeline, or other concerns a mini-design phase, followed by coding, and then QA. This doesn’t
reduce hand-offs, increase collaboration, or balance team utilization.
ü Make the Sprint Review work spectacularly well for stakeholders

to influence direction and provide feedback that you listen to
While individual stories will typically be assigned to a member of the
ü Show the predictability that can come from measuring a release team to lead – they ought to work in a highly integrated, parallel effort
burn-down, and provide (conservative) updates on date ranges with the rest of the team.
ü Work with Engineering Management to secure a strong SCRUM
Master (perhaps train someone), and develop a close partnership For example, Design and “Front-end” Developers should be frequently
with them (don’t try to do the role yourself) heads-down together on the user interface making tweaks and
agreeing work-arounds. QA should be writing unit tests at the same
time developers are coding, so developers can run these tests at any
time when ready to validate their code.


ü Encourage Design and QA to work in parallel with development, War story – Agile and Remote Teams
not sequentially. Design should collaborate with development
while they build features. QA should be preparing the unit tests. Working with remote teams is never easy – but the cost and
ü Use the Retrospective forum, and influence of SCRUM Master and extra capacity can be very advantageous.
Engineering Management, to address. Be direct and clear on the
effects. A client had several Agile teams with members in the US,
Argentina and India. While some work could be independently
ü Monitor team utilization through-out the sprint. Look for these
assigned, generally stories had to be collaborated on across the
warning signs.
team in all locations.

Our strategies?
SCRUMer-Fall Warning Signs

- Design is overworked early-on, while Development reports - We established virtual chat rooms and all-day video hook-up
being blocked as they wait on design (“hand-offs”) between locations
- We paired remote and local developers together, so remote
- Design, Development and/or QA aren’t frequently seen
developers had a single person responsible for responding
working on a story together
quickly to issues
- Development reports “code complete” but story remains - Product Owners were more specific on requirement
open awaiting QA to complete and run tests definition than ideal, still within the bounds of Agile but not
- Stories that were reported as “code complete” are later as open-ended
moved back into active work-in-progress as bugs or other - Where possible, the more predictable, less critical tasks
issues were surfaced within user stories were assigned to remote teams
- QA is severely crunched at the tail-end of the Sprint - To overcome cultural barriers and fear of conflict, we
explicitly asked each team member the stand-up questions
- Demo-ready working code only seems to come together a
and then probed deeper, rather than wait for that
day or two before Sprint Review
information to be proactively volunteered
- Sprint burn-down chart shows most of the stories closed in - When commitments were made, we followed these up with
the last few days of the Sprint detailed, clear emails – to make these clear and transparent
- Sprints tend to go in phases like “design sprint”, “coding - The staff in India shifted their daily routine to late afternoon/
sprint”, “testing sprint” evening to improve working time overlap
- Design is exclusively working one Sprint ahead (on the next
set of stories). [Some of this is needed to flesh out user While not perfect, these strategies worked well without too
stories and conduct validation… but shouldn’t be the focus.] much Agile adaptation required.


A Brief SCRUM and Kanban Comparison

Kanban is another iterative method, developed by Toyota in 1953 to
manage their manufacturing logistics chain – focusing on teamwork,
leadership, customer orientation, efficiency. Kanban is an excellent tool for
start-ups (where priorities change constantly, even faster than a sprint) or
at the start of a project that is nebulous and the team must maximize
flexibility, discovery, and learning.

In common:
Ø Flexibility in planning – Product Backlog is added to, estimated, and
prioritized at any time. The backlog is drawn from top down so the
team is always working on the next most critical tasks.
Ø Focus – Multitasking kills efficiency. The more work items in flight at
any given time, the more context switching, which hinders their path
to completion. Kanban is more aggressive and explicitly limits the total
number of work items in process (additional items are not permitted
to be started till something else is completed). SCRUM achieves a
similar goal by ensuring the team commits to a limited scope over a
constrained time-period.

Differences are:
Ø Metrics – Velocity is the amount of work completed sprint to sprint in
Ø Cadence – SCRUM has a set scope increment over a set time. Kanban SCRUM. The team aims for predictability (estimate and set
uses a continuous flow model, always taking the next in queue and expectations for how much work is reasonable in a given sprint). In
working on it until done. Kanban, Cycle Time is the key metric. It is the amount of time it takes
Ø Release Methodology – SCRUM allows for a unit of business value to for a unit of work to move from start to the moment it ships. Kanban
be delivered each sprint. This has the advantage of a set time for focuses on delivering units of value to the customer in as short a time
customer to see a rich product and provide feedback before as possible.
something is shipped. Kanban allows for a continuous delivery model, Ø Continuous Improvement – SCRUM teams lock in on scope and avoids
of smaller increments, when-ever the team desires. mid-sprint changes to ensure predictability and provide the team with
Ø Roles – SCRUM has defined roles, Kanban does not. Both however a clear goal. However, each new sprint reflects the latest learnings and
place task completion above roles, allowing for resources to easily product backlog priorities. Kanban’s approach is even more flexible:
“swarm” on challenges to deal with issues. any bottlenecks (throughput issues) are surfaced and resources
immediately to flow where they are needed most.


Exercise 1 – Agile Manifesto in Practice Customer Collaboration over contract negotiation

- Focus now on a prototype for engaging and validating with
Imagine you are faced with the following situation. Brainstorm some ways customers (talk with more realtors so you don’t have just one
you could apply the Agile Manifesto principles to address it? opinion)
- Recruit customers to collaborate with the teams on an ongoing
Ø You and your team are delivering the first generation service to real basis to guide development (iterative testing and regular
estate clients. You need to ship in six months. feedback)
Ø The requirements were detailed upfront and the team has been - Align/reset scope expectations, and provide progress updates to
building against the specifications for three months. avoid later issues
Ø The business owner has just shown some of the functionality to large
realtor and the feedback is not positive. Responding to Change over following a plan
- Understand the nature of the feedback and remove or reprioritize
existing features
- Renegotiate constraints on timeline and scope – in exchange for
greater responsiveness and adaptability
Sample Answers
- Start iteratively adding new user stories as you learn more –

allowing some of the original requirements to fall lower in priority
Individuals and Interactions over processes and tools

- Make sure product owner, team and business users are
interacting more frequently (ideally co-located)
- Break out of the “implementation” phase process mentality and
build in smaller cycles of requirements, build, and validate
Exercise 2 – Breaking User Stories into Tasks
- Hold short meetings to discuss progress and blockers to keep
team focused and always problem solving Break the following user story down into about 6-10 tasks…

Working Software over comprehensive documentation Ø Sprint Goal: deliver the basic functionality for users to see a list of
- Set and work towards high-level goals rather than a set of relevant jobs from the database
granular specifications
Ø User Story: “A user can view a list of matching job search results after
- Abandon the requirements document – break the remaining
entering a keyword term”
requirements up, place into backlog, and prioritize by business

value
Think of Set-up, UX Design, Research, Architecture, Data, Engineering
- Start delivering more frequent iterations (2 weeks) focusing on (front and back-end), and Testing steps. Do not just describe specific
working code – progressively reveal more functionality for features or flows, but the set of activities to get there.
evaluation


Sample Answer Sample Answers

- Decide final UX flow based on user feedback (gathered before the Question 1 – requests:
Sprint) ü Thank-you for the feedback. Can you provide more business context
- Design layout of search results page for why those are important so we do a better job anticipating that in
- Make images and assets in Photoshop future?
- Get copy from Marketing or Copy Writer ü Can you please help us get the other team to take action? Who should
- Create a dummy page with a set of canned (“fake”) jobs we reach out to?
- Create API to send keyword, receive results ü Can you help us understand the relative the importance of the new
- Link page and API together feedback against other priorities?
- Add error handling for empty searches or no search matches ü Can we set up a meeting to discuss the impact to the schedule and the
trade-offs we might be faced with?
- Code HTML and CSS for page
ü While we’ll do our best to achieve both, which is more important? Are
- Unit test pages are working (against Acceptance Criteria)
we in a date-driven or scope-driven situation?
- Test API for performance (speed, load)
ü Can you help us get some more direct customer feedback to validate

the feedback further?

ü What else can we do in the future to prevent impediments/lack of

feedback?

- NOT: can we have more resources, can you decide the priorities for us,
Exercise 3 – Sprint Review Commitments can you slip the date, can you tell us what to do

Ø You have completed your demo. You were only able to complete 5 out Question 2 – commitments:
of 9 committed User Stories this Sprint. ü The SM will follow up with the team that didn’t get back to us earlier
ü The SM will escalate to you when lack of responsiveness happens
Ø It isn’t your fault – you were waiting on another team to get you again rather than wait for the demo
information. ü The SM and PO will come back with schedule impacts and options
(scope/quality/time) to move forward
Ø In addition, Stakeholders gave you feedback that looks like it might ü The Team will discuss how we can avoid this happening again in our
impact the schedule. Retrospective
ü The Team will make sure we commit to scope at next Sprint Planning
1. Write down 2 questions/requests you will ask of the senior we know we can deliver
Stakeholders in the room. ü We will give stakeholders an updated deadline confidence level, along
with regular progress reports
2. Write down 2 commitments you will make to Stakeholders. ü Everyone will do more customer validation before and during each
Sprint to do a better job at anticipating these issues
Tip: Stakeholders want to be useful but the Team is accountable - NOT: we’ll work hard to catch up, we’ll take on even more next Sprint,
we will escalate to you every time, we’ll be extra conservative in
future, we’ll address 100% of your feedback immediately

Exercise 4 – Calculating Velocity How to Play:

1. Get a group together (you can make this a multi-player game
with multiple teams – no team should be larger than 7 players)
2. Every group has “100 story points” at the start. But you can
lose story points as your team faces a challenge.
3. The team with the most story points at the end of the Sprint
wins.
4. Pay close attention to the SCRUM Ceremony Key Takeaways
provided in this chapter.
5. Each player in each team is assigned one of these roles:
- Product Owner
- Scrum Master
Answers - UX

(1) 35 – velocity is always the delivered story points - Developers (2)
(2) 28 – it is customary, but not required, to take the average of the - QA
last three Sprints to set the target for the next one. - “Chicken”

Exceptions to this rule include if you expect more than usual If you have less than 7 players, double up (except chicken).
interruptions, if something anomalous happened to make a Sprint’s 6. Place the appropriate card, face up, in front of the assigned
velocity an outlier, or if team members are going to be away on player BUT do not reveal either the front or back until your
vacation. turn (no other players should see the challenge or outcome)
7. Each card will look like this:

Exercise 5 – Agile Ace Card Game

The goal is to learn practical techniques to deal with interruptions and
issues following the Agile process. Total time to play is around 30
minutes.

Download the cards available at the following URL -
http://bit.ly/AgileAceCards. Print them out and paste the front and
back of each card together. A score card can be found here –
http://bit.ly/AgileAceScoreCard.

8. Step 1 – Sprint Planning (3 min) Exercise 6 – Implementing Agile

- Decide your Sprint goal (you do not have to make this a
real Sprint, you can make a hypothetical situation up) This extensive exercise takes you through steps to get SCRUM working
- Select a few stories from your actual or hypothetical in your teams. The Ceremony templates enable you to drive
backlog to “build” during this simulation accountability and capture the outcomes of discussion. You may wish
to complete several cycles to get the team in sync on the new process.
9. Daily SCRUM Stand-up (3 days, 3 min each)
Download the templates available at http://bit.ly/ImplementingAgile.
- Take turns making up a status for the three questions (be
creative) A. Sprint Planning

What did you do yesterday?

1. Discuss and agree an achievable yet meaningful Sprint goal – make
What will you do today? it obtainable over the next iteration. Review the notes on goal setting.
Are there any impediments in your way?
2. Add/update and roughly prioritize User Stories candidates for

- Now each assigned player picks up and reads the challenge consideration over the next Sprint in your Product Backlog – ensure
they are aligned with, and advance you, towards your goal
on the front of their card, according to these turns:

Tip: if there are dependencies between User

Stand-up 1 Developer 1 Stories, list them in the order they must be done.

UX
Stand-up 2 PO 3. Taking each User Story in turn, break it down into implementation
Chicken tasks. Add tasks into the User Story within the backlog (such as
the notes section). – think of tasks as a short “to-do list for each story. Don’t
Stand-up 3 Developer 2 include tasks that you can’t do in the Sprint (this is a sign for a separate story).
QA
Example Task Break-down:
Sprint Review SCRUM Master
Goal: Build a prototype of the Job Search for testing with job seekers

- Do not turn your card over until the team has decided on their User Story: “As job seeker, I can view information about each job that is
action matched by a search” (8)

- Once ready, read the outcome on the back and determine your Prototype Tasks:
resulting Story Points and update the Score Card - Decide changes to UX based on the Usability testing assignment
- Design layout of search results page
10. Sprint Review (3 min) – complete last turn, and finalize Story - Make images and assets in Photoshop
Points - Create a set of canned (“fake”) jobs to show on the search page
11. Sprint Retrospective (10 min) – reconvene as a group and - Code HTML and CSS for page
discuss what you learned from the experience - Test pages are working (they only need to return the canned jobs)

4. Estimate each using Story Points using the best practices outlined a. What they have achieved
in this chapter. If there are different opinions of the size within b. What they are working on next
the team, discuss these differences and see if you can agree on a c. What (if any) impediments or dependencies do they have
revised estimate. – try using planning poker. NOTE: do not estimate each task, from completing their tasks
only User Stories. d. If they need some help from the someone else in the rest of

the team
If you are using Pivotal tracker, the tool expects a 1-3 in the estimate field. Instead,
place your Story Points estimate in brackets at the end of the Card. See example
above – the story points estimate of (8) is listed at the end of the story. 10. Agree on an Action Plan: who will work on these issues to keep
the project moving along – don’t solve the problems at the Stand-up but
make sure you follow up later
5. Decide which of the User Stories you are going to commit to in

the next iteration. Move these over into your Sprint backlog. Keep 11. Fill in the Stand-up Ceremony Notes using the template. Include
going until you feel as a team that you have enough scope to - a short summary of the ceremony (which tasks are
commit to over the next cycle. – your Sprint backlog is a separate list from completed and what issues were brought up) – a short
your Product Backlog. Debate, and don’t be afraid of conflict or commitment. paragraph or bullet points
- an Action plan
6. Once you have enough tasks for a full Sprint, stop. Calculate the - your collective opinion of whether you feel your Sprint is “on-
total number of Story Points you aim to complete – this is your track” or not. Elaborate why.
target Velocity.

7. Go through all the tasks in the Sprint plan and assign a lead within
your team for each – this person will be the key person C. Sprint Review
responsible for making sure it gets done (often with other’s help).
Be sure you have an even workload across the team. 12. About a day before Sprint Review
- Contact key stakeholders to confirm attendance, and to
8. Fill in the Sprint Planning Ceremony Notes using the template. review any concerns they have
Document your goal, target velocity, and include a short summary - Schedule and validate demos are working. Ask the team to do
of issues and next steps. Review and sign-off on the checklist. a “dry-run”. Cut any demo that is not ready (partially finished
stories, last minute changes, technical instability, or if the
presenter won’t practice).
B. Daily SCRUM Stand-up– as short as 15 minutes. Assuming a 2-week cycle and - Sketch out a timed agenda (in partnership with the SM) and
Stand-up is not held on Planning or Review day, you will do four a week.
send to all attendee ahead of the review

9. Meet to review progress. Every team member should volunteer:


13. At the start of the review, remind everyone present (1) what you D. Sprint Retrospective
want to get out of the ceremony (questions, feedback,
celebration), (2) introduce the Sprint Goal and (3) bring up the 20. Have an open conversation about the following topics and
Sprint Backlog on a screen or board. document key points.
- What went well during the Sprint (celebrate!)?
14. As demos are completed make notes for: - What did not go well during the Sprint?
- Any questions or concerns raised by Stakeholders - How is teamwork? What could be improved?
- Any bugs and issues you noticed in the demos - Velocity and Outstanding Stories: If your actual velocity and
- Feedback to give each presenter (did they keep to time, target velocity differ, why do you think that is the case? Were
follow script, skip over areas, need presentation skills all tasks in each story completed? Any stories not “done”,
coaching) why?
- Next steps to follow-up after the review (assign leads to each - Pick 1-3 specific process and collaboration improvements to
and make sure these are followed-up quickly). commit to solve for next Sprint

15. As you go, review the User Stories completed compared to the 21. Fill in the form for your Retrospective Ceremony Notes using the
work you planned to complete. Close the User Stories that you all template.
agree meet the definition of “Done”. Keep open stories that are
not “Done”. – remember there are no “almost dones”

16. Calculate your total Actual Velocity. Compare to your Target
Velocity set during Sprint Planning.

17. Invite an open conversation (see the “Summarize Overall”
questions in the Sprint Review Ceremony section of this Chapter).

18. Wrap-up by celebrating. Review Next Steps, invite positive
feedback, and formally close the Sprint (do it in the backlog tool).

19. Fill in the Sprint Review Ceremony Notes using the template.


Chapter 10 - The Product Managers Role in Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 10 - The Product Managers Role in Development

Uploaded by

Copyright:

Available Formats

Product

Management Essentials Chapter 10 – The Product Manager’s Role in Development

Product Managers Support Engineering

- Management over multiple geographies and/or cultures (not co-

“illusion of predictability” due to a false sense of confidence. Be

Getting all those in to work seamlessly is a challenge. To compensate, Structure of Agile/SCRUM

From a Product Manager’s point of view, each manifesto statement has

Five SCRUM Values

ü Honestly meeting all standards for quality, acceptance criteria,

Three SCRUM Roles

2. Daily SCRUM (Stand-up)

The PO’s primary responsibility in Standups is to observe and get a sense of

3. Sprint Review (Demo)

ü Celebrate – if things are going well, “pre-wire” stakeholders to

Agile Estimation – Story Points and Velocity

Ø Just-in-time/Time-boxed – other than high-level estimates provided at

Ø Planning Poker – while nothing in SCRUM dictates the use of the

How to Play Planning Poker

At the completion of a Sprint the whole Sprint backlog is closed and

Common Agile Pitfalls

Product Management Mitigation:

A Brief SCRUM and Kanban Comparison

Exercise 1 – Agile Manifesto in Practice Customer Collaboration over contract negotiation

Sample Answer Sample Answers

Exercise 4 – Calculating Velocity How to Play:

8. Step 1 – Sprint Planning (3 min) Exercise 6 – Implementing Agile

What did you do yesterday?

Tip: if there are dependencies between User

You might also like