Author: Efrain (Frank) Velazquez

Pass the AWS Solutions Architect Associate Exam

How an AWS noob prepared for and passed the exam

Articles about how to pass AWS certification exams are a dime a dozen.  I know because, when I was preparing for the AWS Solutions Architect Associate certification exam in 2019, I read many.  While I managed to glean a few nuggets of wisdom from some of them, I found most of them to be narrowly focused on study materials, practice tests, and laundry lists of topics that did or did not appear on the author’s exam copy. 

While useful, such content is highly perishable since AWS continually changes their certification exams to align with an ever changing and expanding AWS ecosystem.  It is also somewhat arbitrary since no two test takers will take the same test.  I’m taking a different approach. 

Instead of trying to make sense of the sea of disparate, sometimes contradictory, and often outdated advice, my advice is that you approach studying for the exam systematically.  In other words, organize how you study so that it is effective, less time consuming, and study with the intention of learning how to architect solutions on AWS, rather than learning just enough to pass the exam.  Treat it as an opportunity for professional growth, not just as a way to add another credential to your resume or LinkedIn profile.  Doing so will give you the purpose and motivation you need to knuckle down and do the work.

Oh … and if you are wondering, I passed with a score of 820 out of 1000.  Take that for what it’s worth.

It took me six months to prepare because I had to squeeze study time between full-time work, family obligations, and a forty-minute commute to and from work.  “Your mileage may vary.”

While I have software development experience, my cloud computing experience was practically zero when I began studying.  I mention this to stress that it is possible for an IT professional to pass the exam, even without extensive hands-on AWS experience, so long as that person puts in the time and effort to learn the material and applies it by working on labs or small personal projects.  If you have systems networking or systems administration experience, you’ll have a leg up.

Before delving into how I prepared for the exam, I’ll cover some information about AWS certification exams.

AWS Certification Exams are Difficult

Those of you who have not yet taken one of the AWS associate or professional-level certification exams likely want to know, just how difficult are they?  That is one of the top questions Googled about AWS certification exams; I checked.  They are difficult for most people, even for many who have practical experience managing, developing, and architecting solutions on AWS.  Unfortunately, AWS is tight-lipped about information that could help potential exam takers determine their chances of passing:  Percentage of people who pass or fail, scores required to pass, how often exams are updated, which services will appear on the exams, and even how many people have passed the exams.

So, what makes AWS certification exams so difficult?  In my opinion, the two main factors are the amount of material covered in the exams and how AWS exams structures and conducts the exams.

The Amount of Material Covered is Huge

This is true for all associate and professional certification exams AWS offers.  It is especially so for the AWS Certified Solutions Architect exam because of the need to understand:

  • The capabilities, features and requirements of all of the most used or “core” services in the AWS inventory:   

You can bet services like IAM, EC2, S3, EBS, RDS, DynamoDB, and Elastic Beanstalk will be included but what else does AWS consider to be part of the core?  Lots of folks on the Internet (especially training companies) have their lists, but AWS does not say.

I took a pragmatic approach by focusing on learning the details of the services covered in the AWS Certified Solutions Architect Associate Study Guide and gaining a cursory understanding of other services as I came across them during my studies.  Wikipedia states that AWS had 165 services in 2019.  I did not study them all.

  • How to employ AWS services with respect to the AWS Well-Architected Framework: 

Knowing the services is not enough.  The AWS architectural approach permeates how AWS works and the formulation of best practices for architecting solutions on AWS.   The AWS Well-Architected Framework includes strategies for matching solution workload requirements (e.g., processing, throughput, storage) with AWS best practices to create stable and efficient systems.

Six whitepapers explain the framework.  The first, entitled “The AWS Well-Architected Framework” is an overview that introduces the framework’s five pillars:  Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. Each pillar is described further in its own whitepaper.

I read and re-read these whitepapers and tried to keep the concepts covered in mind when learning about each of the services.

How the Exams are Structured and Conducted

AWS exams are timed multiple-choice exams.  It is not possible to cover every service in the exams.  While I could not find information to back it up, my hunch is that AWS randomizes exam questions from a pool of questions and that the randomization is different for every test taker.  So there really is no way to know what any given exam copy covers and to what level of detail.

  • The multiple-choice questions are tricky:

First, they are scenario-based questions.  AWS is not testing your ability to regurgitate facts or specifications, although you’ll need to know them to arrive at the right answer.  They want to see that you understand the concepts well enough to apply them in specific cases. 

Second, they employ many types of multiple-choice questions:  Single answer, multiple answer, single negative answer (which one of these does not…), and multiple negative answers.  One small detail can render an entire answer wrong.  Some of the questions ask that you to pick the best out of multiple true answers.  You won’t be able to guess your way through the exam.

Taking practice tests is very helpful in getting you thinking in terms of these kinds of questions.  Read the entire question and the entirety of the answers.  The exam shows the number of answers expected before each question, so pay attention and make sure you provide the right number of answers.  You will not get credit for partially correct or incomplete answers.  It is all or nothing.

  • AWS structures the tests around the AWS Well Architected Framework:

Along with knowledge and understating of the services, AWS tests your ability recognize the tradeoffs between different solution approaches based on the pillars of the AWS Well Architected Framework. 

AWS re-contextualizes the five pillars into “domains” that align with the context of each exam.  Here’s how the Five Pillars map to the AWS Solutions Architect Associate Certification exam domains:

Click to Expand
The Five Pillars of a Well-Architected Framework vs. AWS Solutions Architect Associate Certification Exam Domains

AWS breaks out exam scoring across the five domains, not across services.  You must understand the implications of each service with respect to each domain.  Take the time to understand the domains for your exam.

  • The Exams are timed: 

The amount of time available for each question is limited.  For the AWS Solutions Architect Associate certification exam, different sources place the number of questions at between 60 to 70 questions.  Total testing time is 130 minutes.  That’s a little over or under two minutes per question.

You don’t have time to ponder.  The time pressure forces you to quickly assess the scenario, consider the options (the multiple-choice answers), and determine the best one.  The more solid your understanding of the material, the better you’ll be at identifying the obvious wrong answers and considering the rest.  Content knowledge plus good testing skills are key.

How I Studied for the Exam

I was clear on why I wanted the certification: Along with passing the exam, my goal was to gain a good foundational understanding of AWS.  That is why I chose to study for the AWS Certified Solutions Architect Associate exam.  There is significant content overlap across AWS exams.  AWS dropped exam prerequisite requirements, so you have the freedom to take whichever exam you like.  Think about what you want to learn and why before expending effort studying for an AWS certification exam.

I also wanted to get the most from my limited study time.  I knew I had to get organized, so I chose a set of study materials as my main resources and created a study outline.

The Resources I used

I am not endorsing any of the following resources, just listing what I found useful.  New sources of training and information about AWS are popping up all the time, including free AWS-provided online courses, so do your own research and see what makes sense for you from a learning style and cost perspective.

  1. The AWS Certified Solutions Architect Official Study Guide: Associate Exam (AWS Certified Solutions Architect Official: Associate Exam) 1st Edition:

A new version of this book is available for the current exam (SAA-C01).  The book shares quite a bit of the material with the AWS documentation and training web pages, thus saving me from a lot of “hunting and pecking” for information across the vast AWS training library.  The book’s organization of the material served as the basis for my study outline notes.

Aside:  Make sure you are studying for the latest exam and be on the lookout for when AWS is due to release a new exam!  According to AWS, they regularly rotate questions in and out of their certification exams.  AWS publicizes major revisions and smaller changes in exam material covered by each exam.  You can verify by visiting the “Prepare for Your AWS Certification Exam” webpage.

  1. Linux Academy:  They are an online training provider offering, among other courses, AWS certification exam preparation courses.  I signed up with them to get another take on the material, fill in content gaps, identify changes from the book, and gain access to hands-on labs and practice tests.  There are similar offerings out there.  I only used Linux Academy.
  2. AWS Documentation Site
  3. AWS White Papers & Guides
  4. AWS-Related YouTube Videos  Helpful when the written material is unclear or lacking.

My Study Outline

Instead of writing flash cards, I opted to organize the material into an outline.  As I read the study guide, I outlined each chapter’s key points and included additional materials from other resources such as diagrams, tables, passages, etc.  The time I spent building the outline saved me tons of time in review. 

Study Outline Example

I included a table of contents, chapter titles in each header, and page numbers to ease access to specific material.  I used the heading and table of contents functionality in Microsoft Word to keep the document organized.  When I felt I had a finished product, I had the outline printed and bound.  The end product is much easier to carry around than a book and better organized than flash cards.

The outline brought together information from various sources into one place.  It also allowed me to identify when changes to AWS services contradicted the study guide.  Knowing how something worked before and how it works now prepares you to answer correctly regardless of the approach featured on the actual exam.  Condensing a 350-page book into a third of that, with my own notes and references, made review much easier.  The outline also serves as a great reference resource when working with AWS.

In my opinion, the biggest value of building an outline is the practice of leveraging different learning styles at once.  Every person prefers different ways of learning.  Some people prefer reading, others prefer to learn through watching videos, etc.  By combining techniques suited to your preferred learning styles, you become more engaged with the material and, thus, more likely to retain it.  Education theory categorizes learning styles into seven categories:

The Seven Learning Styles

Building the outline got me studying visually, verbally, and physically.  Listening to videos and adding relevant material to the outline got me studying visually, aurally, verbally, and physically.  I prefer studying alone, so all my activities were solitary.  Strive to leverage all your preferred learning styles.  Repetition is the key to learning, so covering the same material in multiple ways can only help you.

Practice Exams

The only practice tests I took were those from Linux Academy.  I found a lot of contradictory reviews concerning other practice test sources, so I stuck with what I already had access to.  Your research may find more or better alternatives.  Nevertheless, if you choose to use an online training provider, take full advantage of their tests.  Linux Academy recommended getting a perfect score at least three times before attempting the actual exam. 

Linux Academy displays a review of every practice test answer (I suspect the same is true of competing services).  The review details which questions the test taker answered correctly or incorrectly and the rationale behind each correct answer.  I researched questions I got wrong and updated my study outline accordingly.  A few times, the practice tests pointed me towards material I had not seen before.

A downside of online practice exams is that the pool of questions may be limited. After a few attempts, you may see repeat questions.  While more practice test questions may help uncover learning gaps, I believe that the biggest benefit of practice tests is familiarization with how AWS phrases questions.  After a while, you’ll start to pick up on which details the exam may likely cover and in which ways.

Review, Review, and then Review Some More

There is no substitute for hard work.  Studying for an AWS certification exam can be a serious time commitment.  I spent hours reviewing my study outline and making updates as I found new information.  What I found gratifying was finding myself regularly thinking about how to best address customer needs, from both a technical perspective and with respect to the AWS Well-Architected Framework, by leveraging AWS.

Conclusion

Attaining any AWS certification is an achievement precisely because they are difficult to attain.  AWS certification exams are steps along learning paths that lead to greater mastery of the platform.  Of course, certifications cannot substitute real-word application.  However, having a firm foundation of knowledge and understanding about the platform will greatly improve your ability manage, develop, and architect solutions on AWS.  The AWS Certified Solutions Architect Associate exam is a great step along the way to becoming a well-rounded cloud engineering professional.



What’s wrong with “Agile Training”?

Disappointed with the results of Agile training? There is a better way.

Your organization spent a lot of money on “Agile training”.  You, your co-workers, and/or subordinates are newly-minted certified practitioners of some flavor of Agile, most likely Scrum.  If your organizational culture is rooted in traditional project management, this may be your first encounter with Agile.  It may also be the case that your training is part of an organizational Agile implementation initiative.  So, how is that initiative going?

If your organizational transition to Agile is like most
others, painfully.  Changing
organizational culture is incredibly hard, no matter which direction that
change takes, and a transition from traditional project management to Agile is
arguably among the toughest.  It is easy,
and dismayingly common, for organizations to slide back into old ways of
working when the going gets tough.

One of the biggest reasons Agile adoption efforts fail is the way many organizations view, not just Agile training, but employee development in general.  They treat employee training and employee development or education as synonymous.  They see training only as standalone discrete activities or events to attend rather than as a vital component of an ongoing employee development strategy.  Thus, many organizations deem receiving an Agile certification after a two-day training class enough for recipients to implement and sustain an Agile approach on their own.  Employee proficiency in Agile, or any other discipline or domain, requires training, education, practical experience, and coaching to prepare employees for the challenges they will encounter implementing the Agile approach at their organizations.

Training vs. Education

Let’s clear up the difference between training and education:

Training vs. Education

A common misconception is that education only happens in an academic setting and everything we learn outside of that setting is training. Education is mainly about learning how to think critically about a subject and developing the ability to leverage knowledge in new ways and in new situations. Where the learning happens and in what context is irrelevant.

Training and Education

Obviously, we want both practical skills and an
understanding of their underlying principles. 
The question is, to what degree?  Should employees learn just enough theory to
support their use of practices and techniques? 
If so, will they have enough mastery of the subject matter to lead its
implementation and overcome all the unforeseen challenges they will
encounter?  On the other hand, how much
theory is enough and how will it translate into measurable business or mission
impact?

As most often happens in the real world, the answer is frustratingly vague; it depends. 

It depends on what the organization wants to achieve and how.  What knowledge, skills, and experience does
the organization need to achieve its goals and objectives?  Organizational strategy must include plans
for attracting, developing, and retaining talent.  The organization may choose to train internal
employees, outsource the work to experts, or blend the two approaches by
providing some level of training while fostering knowledge transfer between
expert consultants and employees.  Each alternative
requires different types of training and
ongoing education. 

At an individual employee level, learning plans must align
with the work employees do in support of business or mission goals and objectives
by bridging the gap between the skills they currently possess and the skills
they need.  One employee may only need a
narrowly defined skill.  For example, a
Scrum Master takes a JIRA class to become more proficient at using the
tool.  Another employee may need to
develop analysis, evaluation, and creative skills commensurate to the ambiguous
and complex nature of their role.  That
employee needs training and educational opportunities that enhance his/her current
education, skills, and experience.  For
example, another Scrum Master expressed an interest in becoming an Agile
coach.  That position requires mastery of
Agile frameworks/approaches, experience implementing them, and skills in
problem solving, leadership, and customer engagement.  That mix of intellectual resources and
abilities comes from a combination of training and education. 

Bloom’s Taxonomy

A good way to frame discussions about balancing employee
development training and education in general, and with respect to Agile
adoption specifically, is by couching them in terms of Bloom’s Taxonomy:

In 1956, Benjamin Bloom with collaborators Max Englehart, Edward Furst, Walter Hill, and David Krathwohl published a framework for categorizing educational goals: Taxonomy of Educational Objectives. Familiarly known as Bloom’s Taxonomy, this framework has been applied by generations of K-12 teachers and college instructors in their teaching.

The framework elaborated by Bloom and his collaborators consisted of six major categories: Knowledge, Comprehension, Application, Analysis, Synthesis, and Evaluation. The categories after Knowledge were presented as “skills and abilities,” with the understanding that knowledge was the necessary precondition for putting these skills and abilities into practice.

This section from “Bloom’s Taxonomy” was copied from the original. Used under CC BY Vanderbilt University, licensed under CC BY Agile Cheetah

Figure 1: Bloom’s Taxonomy

The intent behind the taxonomy was to move education beyond rote memorization to higher levels of learning.  The taxonomy provided educators a construct for developing learning objectives targeted to achieve criteria associated with each category or levels of learning. 

The taxonomy is hierarchical, thus higher levels of learning subsume lower levels.  In other words, before we can comprehend the material, we must first know and be able to recall the ideas, facts, principles, and theories that make up the material.  To apply the material, we must know it and comprehend it, and so on.

In 2001, Lorin Anderson, a former student of Bloom, and David Krathwohl published a revised version of the taxonomy.  Figure 2 below depicts the revised version.

Figure 2: Bloom’s Taxonomy as Revised by Lorin Anderson and David Krathwohl

This work, “Revised Bloom’s Taxonomy”, is a derivative of “Bloom’s Taxonomy“, used under CC BY Vanderbilt University. “Revised Bloom’s Taxonomy” is licensed under CC BY by Agile Cheetah

Agile Training is not Enough

The four tenets of the Agile Manifesto and the 12 Principles of Agile that support those tenets are all that define Agile.  That’s it.  That is the extent of Agile. 

The Agile Manifesto and 12 Principles combined characterize
a vision for a way of working.  They do
not prescribe how to achieve that vision.  Agile leaves the details of implementation
for practitioners and organizations to figure out.  Thus, the proliferation of Agile-based
frameworks and approaches.  Some, like
Scrum, existed prior to the Manifesto and contributed to its inspiration. 

There are no cookbooks for Agile or for Agile-based
frameworks/approaches and it would be foolish to write them.  For Agile implementations to succeed, people
must learn beyond the ability to apply the rules of their chosen Agile approach
as written.  They must be able to align
their ways of working to the Agile approach and understand the consequences
of deviating from its rules.  When
real-world circumstances conflict with implementing the standard approach,
practitioners must be able to:

1) advocate for changes that allow its implementation as per
the standard; or

2) when circumstances cannot be changed, seek ways to modify
the approach without corrupting it or
advocate for a different approach (Agile or non-Agile) that better aligns with project
context and/or organizational culture. 

In turn, organizational leadership must share that level of
knowledge and understanding of the Agile approach to participate in its
adoption (as opposed to merely lending support) in ways that move the
implementation forward.

A two-day introductory Scrum (or any other Agile-based
approach) certification class is not enough to get people to that level of
mastery over the framework.  That training event is only a starting
point.  At best, students walk away
with a certification that only attests to their ability to remember the
training material with a cursory understanding of how to apply it.

The Alternative

As depicted in Figure 3 below, mastery over the Agile-based approach increases as learning progresses up the taxonomy.  A combination of ongoing skills training, practical application/experience, education, and coaching get practitioners up the mastery slope.

Figure 3: Levels of Agile Approach Mastery

The goal is not to make everyone an Agile coach.  Instead, it is to prepare employees and
organizational leadership for the roles they will assume as participants in the
Agile implementation.  Everyone involved
must:

  • Know the Agile Manifesto, the 12 Principles, and
    the rules of the chosen Agile framework/approach well enough to recall them in
    detail (Remember)
  • Understand the foundational material well enough
    to explain it and recognize its proper implementation (Understand)
  • Be able to apply the rules of the approach in
    accordance with the Agile Manifesto and the 12 Principles (Apply)

The bottom three learning levels represent the learning
levels required to effectively participate in an Agile implementation.  They also serve as the foundation for the
higher order learning required to successfully establish and maintain an Agile
implementation. 

Proficiency at the first three levels equates to the ability
to “do” Agile.  It demonstrates an
understanding of the rules and mechanics of the approach.  Further practice, coaching, and independent
study set the stage for further progression up the taxonomy.  Participants gain valuable insights along the
way which further clarify and reinforce their understanding of the framework/approach.

In short
time, participants begin acquiring skills from
the top three learning levels of the taxonomy. 
This is an opportunity to build on the hard-won knowledge, skills, and
insights they gained at the lower levels. 
Coaching and self-study are particularly effective ways to foster further
Agile approach mastery. An effective employee development plan includes additional
training that addresses higher-order skillset gaps.  These training gaps could be related to the Agile
approach, technical knowledge, or “soft skills” such as leadership and
communication. 

As participants mature as Agilists, their own curiosity motivates
them to seek ways to further their mastery and to try innovative approaches
that best align to their work and organizational context.  At this level, the emphasis shifts from “doing”
Agile to “being” Agile.

Conclusion

Agile is a simple construct. That does not make its implementation easy. The biggest hurdle to successful Agile adoption is not learning the mechanics of an Agile approach. It is, instead, overcoming the cultural baggage of over 150 years of Taylorist-based project management culture. That culture has been the dominant managerial culture for most of that time and Agile is a radical departure from that mindset. That is precisely why ongoing training and education are so vital to the successful implementation of Agile.



Deliver Valuable Solutions through Scrum (Part III)

Leveraging Impact Maps, User Story Maps, and Product Roadmaps to Align Organizational and IT Product Strategy using Scrum

This is the third and final part of a three-part blog series about aligning IT solutions/capabilities to organizational needs via an Agile-Scrum product management approach. You’ll find part one here and part two here.

In this article, I walk through how a Scrum Product Owner (PO), in collaboration with the rest of the Scrum Team and others, might bridge the “Product Management Vacuum” discussed in part II by  leveraging impact maps, User Story maps, and product roadmaps for Product Backlog refinement and release planning.

Part II Recap

In part II, I explained how the PO, as part of the Scrum Team, serves as the linchpin connecting the Scrum Team to the larger organizational product management structure.  The PO is responsible for fostering and maintaining ongoing collaboration between and among the Scrum Team(s), project/solution sponsors and stakeholders, customers, and end users to:

  • Define and maximize IT solution value in terms of expected and realized business/mission value
  • Define a product vision and strategy that aligns with organizational vision and strategy
  • Align the work performed by development teams to product vision and strategy

This product management function bridges what Ralph Jocham and Don McGreal call the “Product Management Vacuum.”   In the absence of a true product strategy, many organizations fill the vacuum with traditional project management activities that focus on managing tasks and people, rather than on defining the product/solution and improving development processes.  This typically leads to wasted effort borne out of disconnects between the Scrum Team, the sponsor organization, customers, and end users.

Finally, I introduced Jocham’s and McGreal’s “Three Vs” construct.  The “Three Vs” – Vision, Value, and Validation – sum up the product definition/management activities POs lead as part of their role.  The “Three Vs” are mutually dependent and reinforcing:

  • Vision drives the creation of value (features/functionality)
  • Value created enables validation of business assumptions behind product development choices
  • Validation informs changes to the product vision

The Official Scrum Artifacts

I am taking the time to clarify that most of the artifacts I discuss in this article are not official Scrum artifacts. The Scrum framework includes three official artifacts:  the Product Backlog, the Sprint Backlog, and the Increment.

The Product Backlog

According to the Scrum Guide, the Product Backlog:

…is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

  • The Product Backlog is the single source of requirements for a product/solution
  • Only the features and functionality compiled and ordered in the Product Backlog make it into the product
  • Helps the PO manage development scope
  • The PO owns the Product Backlog
  • Tracks product requirements evolution as the product and its environment change towards providing greater value

The Sprint Backlog

The Scrum Guide describes the Sprint Backlog as:

…the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

  • The Sprint Backlog makes visible all the work the Development Team plans to do during the Sprint
  • The highest ordered Product Backlog items become Sprint Backlog items
  • Sprint Backlog items have enough detail for the Development Team to understand what needs to be done
  • The Development Teams owns the Sprint Backlog
  • Only the Development Team can change its Sprint Backlog during a Sprint
  • The Development Team tracks progress and changes in work scope through the Sprint Backlog

The Increment

The Scrum Guide defines the Increment as:

…the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

  • The increment is not just what the Development Team develops during the current Sprint. It includes whatever system/solution functionality the team developed in previous sprints
  • Every new Increment must be “Done” at the end of the Sprint
  • A “Done” increment meets the Scrum Team’s Definition of “Done”
  • A “Done” increment is ready for release and capable of providing usable and valuable functionality regardless of whether the PO decides to release it

Product Backlog Refinement

Product Backlog refinement is the management of product requirements by the Scrum Team.  The PO leads Product Backlog refinement in collaboration with the rest of the Scrum Team (i.e., the Development Team and Scrum Master) and with input from product/project sponsors, stakeholders, customers, and end users.  During Product Backlog refinement:

As the product evolves, higher ordered Product Backlog items become more detailed and the estimates become more precise.  With help from the PO, the Development Team defines and decomposes the highest ordered items they plan to work during the next iteration/Sprint into User Stories. The Development Team manages those stories in the Sprint Backlog.

Product Backlog refinement is an ongoing process.  The Scrum Team decides how and when to refine
the Product Backlog.  However, the Scrum
Guide recommends the Scrum Team expend no more than 10% of its “capacity”
(i.e., the sum of productive hours across the team) on Product Backlog
refinement.  Product Backlog refinement is
not restricted to specific timeframes or meetings.  The PO can make changes to the backlog at any
time or have others do so at his/her discretion.

A Product Management Scenario Example

In part I of this series, I discussed organizational and product visions and strategies generically.  To help visualize how all the parts fit together, I walk through a product definition and management scenario.

Over the last year, an online retailer has experienced a significant loss of market share to competitors.  The company investigated reasons for the drop in returning customers and new registrations.  The findings boiled down to customer dissatisfaction with business service functions across the value chain that negatively impacted the company’s reputation.  While the company enjoyed an early market lead for years, competitors were quickly closing the gap with more innovative customer-centric service options and better delivery performance.  The most significant problems found were:

  • Delivery problems
    • Customers receiving their orders late at a quarterly rate higher than industry average
    • Customer orders lost at a quarterly rate higher than industry average
    • Customers receiving the wrong orders at a quarterly rate higher than industry average
  • Customer service issues
    • Customer complaints about being bounced from one customer representative to another with a lack of continuity between representatives
    • Customer complaints about needing faster and more accessible help with “non-standard” issues requiring additional attention
    • Customer wish for an online customer service feedback option integrated with their ordering experience
  • Falling behind in offering new payment service options (Paypal, Google Pay, etc.)

Management shifted company strategy from a narrow focus on delivering
an “outstanding” website experience to improving the entire buying experience,
from online shopping to product delivery. 
They revamped the company’s vision to match this new value stream-based
approach to customer satisfaction and updated their business strategy to
support it.

Company leadership recognized that a lack of customer focus caused the company to fall behind competitors and a subsequent decline in customer satisfaction.  To address this, the company changed how it defines its services by instituting a product management approach.  The company started looking at its website as a collection of online service offerings.  Company strategy needed to be tightly coupled to customer needs and demands, changing as the market changes.

The table below breaks out the flow down of strategic vision and business strategy to tactical product vision and strategy I explained in part I of this series.  The area highlighted in yellow is the “Product Management Vacuum” filled by organizational product management and POs in collaboration with the Scrum Team and with input from project/solution sponsors, stakeholders, customers, and end users.  I focus on the strategic goal to increase customer retention and acquisition through better customer service down to the tactical goal of improving the company’s Customer Service System.  Text of that tactical goal and its decomposed elements is colored red.

Table 1: Strategic Strategy to Product Strategy Decomposition

Defining Product Features

Armed with product goals, the PO works with the Scrum Team and others to define features they believe will help achieve them based on their current understanding of the business and market context.  The Scrum Team continually refines that understanding as the Scrum Team releases features to users.  The ultimate validation of the business assumptions behind new features is end-user validation.   New insights shape future features/capabilities and business/mission strategic and tactical strategies.

This picture depicts the interplay between organizational and product strategy validation.
Figure 1: Ongoing Organizational and Product Strategy Validation

Impact Mapping

Impact mapping is a strategic planning technique Scrum Teams
can leverage to develop Product Backlog items such as Epics and User Stories as
extensions to a defined product strategy. Impact maps are a great tool for
visualizing alignment from product vision to coarse-grained product backlog
items that Scrum Teams can order and further decompose and refine over time.

The diagram below depicts the use of an impact map to decompose the product vision and product objectives for the Customer Service System.  One or more coarse-grained Product Backlog items support each product objective.  These backlog items will collectively form the initial version of system requirements.  Over the course of Product Backlog refinement and Sprint Planning, the Scrum Team refines these items into User Stories.  Each backlog item includes of three elements:

  • Actor – The role for whom the backlog item is for.  The beneficiary of new feature functionality
  • Impact – The desired outcome from using the feature
    functionality
  • Deliverable – The new feature functionality that will
    help the actor achieve the desired impact

We avoid creating compound requirements.  In other words, each backlog item is specific to one role, one deliverable, and one impact.  These are high-level requirements, so the Scrum Team will identify, through their decomposition, different flavors of the same type of actor (e.g., administrator vs. regular user), related impacts for different flavors of actor, and related deliverables/features.  It is important to remember that these are system/solution-level items.  Too much specification now is counter-productive.

This is an impact map example.
Figure 2: Impact Map

Product Backlog

Product Backlog Recap

After defining a set of course-grained requirements, we create the initial version of the Product Backlog.  The Scrum Team writes requirements in the form of Epics and User Stories.  User Stories are backlog items the Development Team estimates will take no more than one Sprint to complete and make ready for release, while Epics are estimated to take more than one Sprint.  The Scrum Team decomposes Epics into User Stories as part of Product Backlog refinement.

At this point, we do not know how long it will take to complete each backlog item, so we do not know which items are Epics vs. User Stories.  It is likely that these coarse-grained items will be Epics but I call them User Stories and group them under “themes.”  The concept of themes is not part of the Scrum framework but they can come in handy when structuring the Product Backlog.  Scrum does recommend adding backlog attributes to group items when multiple Scrum Teams are working from the same backlog.

The Product Backlog table below maps each backlog item to the desired impacts and product objectives listed in in the impact map.  The product objectives become the value measures by which we measure whether each item’s feature delivers the expected business impact/outcome.  I highlighted the Actor and Deliverable elements in each User Story.

This table represents a Product Backlog
Table 2: Initial Product Backlog

Based on the coarse-grained User Stories listed in the table above, the Scrum Team knows enough about what it plans to build to provide the Customer Service System’s tactical plan.

Table 3: Tactical Goal Decomposition with Tactical Plans

User Story Sizing and Product Backlog Ordering

I will not go into detail about how to size and order Product Backlog items in this article.  However, I will highlight some key points that support the topics covered in this article:

  • The Scrum Guide refers to estimates rather than sizes.  However, the most popular estimation techniques in Scrum leverage the concept of “relative sizing.”  Instead of attempting to estimate how long it will take to complete a User Story, Scrum Teams use techniques like Planning Poker to estimate the story’s “size” relative to the other Product Backlog items.  Relative sizing is faster to do, more intuitive, and becomes increasingly more accurate as the Scrum Team “matures” than estimating in hours.
  • As part of the Scrum Team, the Development Team is solely responsible for all estimates.  The PO provides the business/mission context the Development Team needs to estimate the relative size of each Product Backlog item.
  • Typically, Scrum Teams estimate User Story sizes in “story points”, with “larger” stories earning higher point estimates.  Often, the point scale used is the Fibonacci Series or a modified version of it.  Story points are heuristically determined, numerical representations of User Story complexity, risk, uncertainty, and level of effort combined.
  • By tracking the number of User Story points the Scrum Team completes across multiple Sprints (at least three Sprints), the team determines its “velocity.”  Scrum Team velocity is a heuristic measure of a Scrum Team’s throughput (not productivity).  It is the rate at which a team delivers fully completed, tested, and accepted User Stories during a Sprint.
  • Scrum replaced Product Backlog “prioritization” with “ordering.”  Ordering better connotes the concept of ongoing backlog refinement.  Rather than periodically prioritizing backlog items according to vague business value categorizations, like High, Medium, and Low, and awarding multiple items the same priority, the Scrum Team continually orders backlog items based on their business value, risk, cost/size, and dependencies.
  • As User Stories rise in order, the Scrum Team fleshes out story details, provides more precise story point estimates, and decomposes larger stories into smaller stories the team can complete during a Sprint.

User Story Mapping

What are User Story Maps?

A Product Backlog is essentially an ordered queue.  As the number of User Stories grows, it
becomes increasingly difficult see how all of the stories come together into a
system/solution.  This is especially true
for solutions that involve workflows.  A
list of ordered features, written as User Stories, does not communicate how
those features work together and what dependencies exist between them.

Scrum Teams can use User Story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases.  Scrum Teams may use User Story maps in tandem with Product Backlogs to help identify dependencies as part of backlog refinement.  It is a valuable tool to help plan releases as well.

Below is a User Story map example.  The map is a simplified workflow for coarse-grained User Stories #4 and #5 in the initial Product Backlog I discussed earlier in this article.  The User Stories read:

4. As a customer, I want the choice to provide feedback about the customer service I received so that I can communicate whether my issue was resolved to my satisfaction and why.

5. As a Customer Service Representative, I want access to customer feedback about issues I handle so that I learn how best to improve my performance.

The deliverable for User Story #4, listed in the example impact map, is a user feedback form.  However, as described in User Story #5, there is much more to the form then just a webpage to enter data.  The Scrum Team needs to develop a workflow that links multiple roles across the organization.  User Story #5 is likely an Epic in need of decomposition while User Story #4 is likely a User Story the Development Team can finish in one Sprint.  As Product Backlog refinement occurs, the scope of individual stories and of the entire workflow likely changes.

In this workflow, the Customer Service Coordinator reviews
incoming feedback submittals, categorizes them, and assigns them to the
appropriate part of the organization for resolution/acknowledgement.  Should the initial assignment be inappropriate
or fail to yield a satisfactory outcome, the Customer Service Coordinator works
across the organization to identify the right people to address the
feedback.  Otherwise, the customer
receives a response.

Below is a sample User Story map for this workflow.

Table 4: User Story Map Example

Let us walk through the User Story map’s elements:

Table 5: User Story Map Element Descriptions

The yellow cells in the User Story map example represent individual User Stories decomposed from the Epic directly above them in the “Walking Skeleton.”  This decomposition is not one person’s idea of how the Epic should be broken down, not even the PO’s.  It is instead the result of ongoing collaboration within the Scrum Team, informed by project sponsors and stakeholders, customers, and end users, and synthesized into a coherent product vision and strategy by the PO.

Development of a User Story map is an iterative process.  As the solution takes shape iteratively and incrementally, more users, User Stories, business activities, and business tasks emerge, requiring changes to the User Story map and the Product Backlog.  Fundamental changes in approach, predicated by insights learned during product validation, with actual customers and end users, may require changes to the product vision and strategy as well.

Product Roadmap

A product roadmap is a planning tool used to visualize when Scrum Teams estimate they will complete coarse-grained capabilities/Epics and in what order, over a given time horizon.  A product roadmap facilitates planning, not just for the Scrum Team, but also for project stakeholders outside the Scrum Team.  Common uses for product roadmaps include:

  • Communicating status and longer-term plans to
    organizational decision makers
  • Identifying business/mission dependencies across
    planned releases
  • Informs longer term business/mission planning
    (e.g., funding, contracting, agreements with external partners)

A product roadmap is
not a schedule.  It is a snapshot of
current planning, not a set of fixed milestone delivery dates.  Short-term release timelines (no more than
three Sprints ahead) are based on User Story sizing and ordering (done as part
of Product Backlog refinement) as well as demonstrated Scrum Team
velocity.  The PO bases longer-term
release timelines on the rank order of lower-ordered Product Backlog items and
current knowledge of dependencies between those items. 

Like everything else in Agile and Scrum, product roadmaps
are always subject to change.  As the
solution emerges and new learning happens, plans change.  Agile planning is adaptive planning. Rather than creating detailed plans that span
months or years, Scrum Teams wait until “the last responsible moment” to plan only
the highest-ordered Product Backlog items in detail.

The recommended time horizon for Scrum Team planning is no
more than the next Sprint and two Sprints beyond that.  Based on the recommended two to four-week
Sprint length, that is no more than 12 weeks. 
The amount of implementation detail behind a User Story increases the
closer that story comes to being implemented by the Scrum Team.  User Stories planned for the next Sprint are
much more detailed, and their estimates are better informed, than lower ordered
User Stories tentatively scheduled for later Sprints.  Therefore, plans to implement solution
functionality beyond the next three Sprints are highly imprecise and likely to
change.

The sample Product Roadmap below maps the product strategy components I discuss throughout this article into a quarterly based plan for the year.

Table 6: Product Roadmap

Release Strategy

Depending on the size of the sponsor organization/company,
the PO either contributes to an organizationally agreed-upon release strategy
or collaborates with the Scrum Team, project sponsors and stakeholders,
customers, and end users in developing one. 
A product release strategy dictates:

  • Release Frequency – How often Scrum Team(s) release functionality: the more frequently, the better.  In Waterfall projects, there may only be only one a major release at the end of development. Release frequency for Agile/Scrum Teams ranges from releasing once at the end of each Sprint, to releasing multiple times throughout each Sprint, to achieving a steady flow of “done” functionality released on “demand” (Releasing functionality when customers/end users are ready to accept it)
  • Validation Frequency – How often customers and end users validate newly released functionality.  Obviously, the more often Scrum Teams release functionality, the more opportunities for validation exist

Market/mission demands drive release strategy. The sponsor organization must train, equip, and empower Development Teams and operations staff so they may deliver at a speed and cadence that matches demand. This is where DevOps plays a huge role.

In our company example, the company’s release strategy is to release at the end of every four-week Sprint.  Scrum Teams monitor usage and performance metrics for the capabilities they release and the organization monitors customer feedback.

Table 7: Tactical Goal Decomposition with Release Strategy

Release Planning

The product roadmap provides a high-level, “broad strokes”
view of how planned releases fit together over an extended period of time.  The Scrum Team plans releases at a greater
level of detail and across much shorter timeframes (no more than three
Sprints).  A PO develops a release plan,
which aligns with the operative release strategy, in collaboration with the
rest of the Scrum Team, project sponsors and stakeholders, customers, and end
users.  A release plan takes into account
the following considerations:

  • The Scrum Team’s capacity to develop “done”
    capability at a sustainable pace
  • Technical and business/mission dependencies on
    or arising from planned functionality
  • The ability and willingness of customers and end
    users to “absorb” or accept planned changes
  • Alignment with business/mission strategy and
    product strategy

Just like a product roadmap, the release plan is subject to change.  Certainty over what a Development Team will develop and release over the next three Sprints is greatest for the next Sprint and becomes progressively less certain for the next two. However, since the release plan’s time horizon is so short and immediate, the frequency and magnitude of the changes should be significantly less than for a product roadmap. 

Below is an example of a release plan for the Customer Feedback Workflow capability based on the User Story map discussed earlier:

Table 8: Release Plan

Conclusion

Scrum is a framework and as such avoids over-prescribing practices and artifacts. The expectation is that practitioners will adhere to its rules and tailor existing processes to align with the framework, not the other way around. The concepts and tools presented in this series are meant to be used as enablers for aligning organizational vision and business strategy with product vision and strategy using Scrum.

Scrum has an inherent product management bias that is a definite departure from the traditional project management mentality that has reigned over organizational IT for decades. A product management approach to organizational IT shifts project-centric, internally-focused sponsor organizations towards putting the customer first and focusing on achieving outcomes, rather than executing plans.



Minimum Viable Products (MVPs) are Built Incrementally & Iteratively

How to build an MVP