This week we go back to basics and answer a listener’s question (name and a bit of the context changed to protect the involved parties). In the essay this week we discuss why it is a rotten idea to have a functional product owner and a technical product owner. When it comes to product owners the old adage, “the more the merrier,” does not hold.

Also, we have an installment of Tony Timbol’s “To Tell A Story” column. In this installment, Tony discusses how to synchronize team-level agile with a waterfall requirements process. This is one of those scenarios that when you run into it you will need to find a way to deal with it until more of the organization embraces agile. 

Tony’s Website:


Large switch

Requirements are more than just on or off!

The Kano Model is a tool to help categorize product requirements.  The model created by Professor Kano groups all requirements into five categories:

  1. Must-be Quality, also known as basic needs,
  2. One-dimensional Quality, also known as performance attributes,
  3. Attractive Quality, also known as delighters,
  4. Indifferent Quality (neither improve or detract from satisfaction), and
  5. Reverse Quality (reduce satisfaction when achieved).

Most typical implementations of the Kano model tend to focus on the first three areas.   (more…)

Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 427 begins with an essay on the Post-Agile Age, titled Onward to Post-Agile Age.  The Post-Agile Age is coming and it is a bed that human nature and commercial pressures have created.

Next Jeremy Berriault brings his QA Corner to the Cast to discuss how he views the role of product owner in Agile testing . Visit Jermey’s new blog at

The Software Sensei, Kim Pries, discusses requirements and weird tools like the Z notation.  Reach out to Kim on LinkedIn.

Jon M Quigley, brings his column, the Alpha and Omega of Product Development to the cast.  In this installment, Jon concludes a three part series on configuration management.  This week Jon puts all of the pieces together. One of the places you can find Jon is at Value Transformation LLC.

Re-Read Saturday News

This week we start to get into the nitty gritty of our re-read of Carol Dweck’s Mindset: The New Psychology of Success. This week we discuss Chapter one and then explore some the applications of the mindset concepts to coaching.   (more…)


Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast features four columns.  We begin with our essay on recognizing risk and risk tolerance.  Any discussion of risk begins with acknowledging that risk exists and then recognizing specific risks.  Once we know risks exist we need to determine which risks we care about. Risk tolerance affects how everyone in an organization behaves.

Kim Pries the Software Sensei discussers change models, focusing on the Kotter model of change.  Kim discusses how change models can be used for hardware, software, processes and procedures.  

Gene Hughson brings his wonderful Form Follows Function Blog the podcast.  In this installment, Gene and I discuss All Aboard the Innovation Band Wagon. We talked a lot about how to define innovation AND why innovation and change is powerful.

Jon Quigley anchors the cast with the third installment in a three-part arc on requirements in his  “The Alpha-Omega of Product Development” column. This week Jon discusses managing requirements.

Re-Read Saturday News

We continue the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  We seem to be moving from cliffhanger to cliffhanger over the past few weeks, and we shall do so again today. Lencioni uses crises to illustrate common problems that make teams into dysfunctional collections of individuals. This week we tackle the the sections from Entering the Danger to Rebound.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.


The Software Process and Measurement Cast 416 will feature our interview with Kirk Botula.  Kirk is the CEO of the CMMI Institute.  Kirk and I talked about organizational capability and why capability is crucial for organizational health and agility!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his  “The Alpha-Omega of Product Development” column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast.  In this visit, Gene discusses his recent blog entry titled, “Organizations as Systems – “Uneasy Lies the Head that Wears the Crown”.  Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute. (more…)

Listen Now

Subscribe on iTunes

The first full Software Process and Measurement Cast posted on January 29th, 2007.  When the first cast posted we were on an every other week schedule whereas today we post weekly.  Over the next few weeks, I will be traveling.  The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.  In place of our normal format, I will post a mixtape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 – Will McKnight on Process and Product Quality Assurance

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 – Stasia Iwanicki on Six Sigma

Stasia used her first wish to address requirements capture, development, and management.  Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 – Robin Goldsmith on Requirements

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2009!

Stories help you visualize your goals

Stories help you visualize your goals

In the Harvard Business Review article, The Irresistible Power of Storytelling as a Strategic Business Tool by Harrison Monarth (March 11, 2014), Keith Quesenberry notes:

People are attracted to stories because we’re social creatures and we relate to other people.

The power of storytelling is that it helps us understand each other and develop empathy. Storytelling is a tool that is useful for presentations, but also to help people frame their thoughts and for gathering information. A story provides both a deeper and more nuanced connection with information than most lists of PowerPoint bullets or even structured requirements documents. Here are just a few scenarios (other than presentations) where stories can be useful: (more…)

Its all about finding the balance!

Its all about finding the balance!

During the heart of winter, when the polar vortex swoops down with temperatures that even my dog finds uncomfortable, my wife and I assemble puzzles.  The act of assembling a puzzle is a simple example of the need to balance a system view with a more detailed perspective.  Getting work done efficiently and effectively requires both perspectives in some sort of balance.

The process we use for assembling a puzzle begins with opening the box, spilling the contents on a handy table and then propping up the lid so we can reference the big picture.  I once had a conversation in a hotel bar with a person who told me that he thought using the picture as a reference was cheating.  A little probing suggested that starting puzzles might have been more his actual goal than completing them, due to the time it took to discover the picture.  In our process, by contrast, I use completion of the puzzle as the goal and the picture on the cover of the box acts as the high-level requirements. However, as anyone that has ever assembled a puzzle will tell you, to achieve your goal you still need to fit all of those little pieces together.  Whether the puzzle you are working on has 100, 500 or 1000 pieces you will have to shift from focusing on the big picture to focusing on the details to find the right fit. The information from both perspectives is essential to fully understand what is required to get from the start of the system to the end of the system in an effective and efficient manner.

Reflecting back to my conversation about puzzles in the hotel bar, by eschewing the big picture, the systems thinking view, my neighbor might have been able to complete the puzzle, but not in the most efficient manner.  Meanwhile, a single-minded focus on the big picture, as pointed out in Gene Hughson’s comments to Systems Thinking: Difficulties can cause the equality serious problem of analysis paralysis. Spinning down into greater or greater levels of detailed analysis means a team is delaying its ability to deliver business value.  Gene was interviewed for the Software Process and Measurement Cast 268 providing great insights into Agile architecture, software development and management.

In the end, both perspectives are needed to get the job done. Finding the balance between the macro- (systems thinking) and micro-focus is a process in its own right.  The balance changes over the life of any project or even iteration. As a team shifts from conceptualizing to developing what is to be done they naturally shift from the big picture to the detailed view.  Product owners face a similar journey between the big picture and the detail, however they need to own the goal and the picture on the puzzle’s lid.  As a coach, the scrum master needs to make sure the whole team remembers the overall goal and big picture. Systems thinking helps us to understand that nothing happens in a vacuum.  Developing an understanding of how we transform inputs into value is critical. However in order to deliver that value, just having the big picture understanding is not sufficient. In order to actually execute, we need to have a handle on the detail also.

Agile re-defines acceptance testing as a “formal description of the behavior of a software product[1].”

Agile re-defines acceptance testing as a “formal description of the behavior of a software product[1].”

User acceptance test (UAT) is a process that confirms that the output of a project meets the business needs and requirements. Classically, UAT would happen at the end of a project or release. Agile spreads UAT across the entire product development life cycle re-defining acceptance testing as a “formal description of the behavior of a software product[1].” By redefining acceptance testing as a description of what the software does (or is supposed to do) that can be proved (the testing part), Agile makes acceptance more important than ever by making it integral across the entire Agile life cycle.

Agile begins the acceptance testing process as requirements are being discovered. Acceptance tests are developed as part of the of the requirements life cycle in an Agile project because acceptance test cases are a form of requirements in their own right. The acceptance tests are part of the overall requirements, adding depth and granularity to the brevity of the classic user story format (persona, goal, benefit). Just like user stories, there is often a hierarchy of granularity from an epic to a user story. The acceptance tests that describe a feature or epic need to be decomposed in lock step with the decomposition of features and epics into user stories. Institutionalizing the process of generating acceptance tests at the feature and epic level and then breaking the stories and acceptance test cases down as part of grooming is a mechanism to synchronize scaled projects (we will dive into greater detail on this topic in a later entry).

As stories are accepted into sprints and development begins, acceptance test cases become a form of executable specifications. Because the acceptance test describes what the user wants the system to do, then the functionality of the code can be compared to the expected outcome of the acceptance test case to guide the developer.

When development of user stories is done the acceptance test cases provide a final feedback step to prove completion. The output of acceptance testing is a reflection of functional testing that can be replicated as part of the demo process. Typically, acceptance test cases are written by users (often Product Owners or subject matter experts) and reflect what the system is supposed to do for the business. Ultimately, it provides proof to the user community that the team (or teams) are delivering what is expected.

As one sprint follows another, the acceptance test cases from earlier sprints are often recast as functional regression tests cases in later sprints.

Agile user acceptance testing is a direct reflection of functional specifications that guide coding, provide basis for demos and finally, ensure that later changes don’t break functions that were develop and accepted in earlier sprints. UAT in an Agile project is more rigorous and timely than the classic end of project UAT found in waterfall projects.

[1], September 2015