Use Kanban to manage processes that span multiple functional organizations and management hierarchies.
If you’ve ever implemented Kanban in a large organization, you’ve probably struggled with scaling small-team Kanban practices. How do you leverage Kanban boards to manage processes that span multiple functional organizations and management hierarchies? This video shows you how.
Learn the best practices and avoid the six most common mistakes
Table of Contents
One of the most frequently discussed topics in Agile and Scrum circles is how to write user stories. Technically, there is no one way to write a user story, however, there are widely accepted best practices. This article discusses those best practices and the six most common mistakes developers make when writing user stories.
User stories (and epics) are not part of the Scrum framework. User stories are one of a number of complimentary practices or techniques many Agilists erroneously believe are part of Scrum.
“Adding on” practices that support the framework and promote agility is an intentional feature of Scrum. As expected for any framework, we can add anything to Scrum as long as it does not contradict or undermine the framework. Take away any element of the framework itself, and you are no longer practicing Scrum.
User stories are, in essence, functional requirements. Functional requirements specify what a product/system/solution must do to satisfy business or mission needs. In other words, what functionality or capabilities will the system include to provide business or mission value? Traditional functional requirements are written from the perspective of what the system must do:
The system shall <do something>
For example:
The system shall allow users to upload xyz reports.
User stories are written from the perspective of what users need from the system to accomplish an outcome. The most popular user story template is:
As <a user, role, or automated client> I want <some capability> so that <desired outcome>
This way of writing requirements puts the user front and center and tells us: (originally posted here)
Below is an example of a well-written user story: (originally posted here)
As a payroll analyst, I want to upload xyz reports so that I don’t have to manually input their contents.
We now know who needs the upload capability and for what purpose. The role of the user is important because it alludes to the kind of data we are talking about: payroll data. The outcome lets us know that the system is expected to do something with xyz report data, so this is not just an archival function. User stories are reminders of further conversations about what is needed, and this user story identifies the user to talk to, what they need, and why. This is enough information to get the conversation started.
It is not enough to know what the system must do. How would we know if the resulting functionality achieved its business or mission intent? Also, how well must resulting system functionality do its job? To be more specific, what behaviors and performance characteristics (Non-Functional Requirements (NFRs)) must the functionality exhibit to address user needs? User stories address these questions via acceptance criteria.
Acceptance criteria are the results or outcomes the functionality must achieve when executed. We demonstrate adherence to acceptance criteria through testing. Acceptance criteria serve as test criteria for the user story.
Well-written acceptance criteria are testable. That means that the result is not left to interpretation. The feature either delivered expected results or did not. The behavior and performance the feature demonstrates should contribute to (or not degrade) overall system-level behavior and performance.[1]
Acceptance criteria for the user story example above could look like this:
Like any requirement, user stories must be well-formed. Well-formed user stories adhere to the INVEST criteria. They are:
The following are the six most common mistakes developers make when writing user stories:
Learn how bad user stories lead to bad value delivery
As explained earlier, user stories are requirements. A product backlog is not a list of to-dos for developers. User stories document the functional scope of the solution from the perspective of its users or clients (human or automated). User stories are business or mission facing. Both business/mission stakeholders and developers should be able to understand the capabilities described in each and every user story.
A user story that reads like this:
As a developer, I need to build an xyz report upload capability.
places the focus on what the developer needs to do rather than what the user needs. We lose the context behind what the xyx report upload capability needs to be, for whom, and why.
Worse is this example:
As a developer, I need to install and configure a SQL database.
In this example, we don’t know what the database is for. On its own, a database is not a business or mission facing capability that users can use. It is a component. Agile value delivery is based on complete and valuable features, not on delivering the individual components that make up features. Along with being requirements, user stories represent the features developers build to satisfy each requirement.
A user story like the one below reads like a traditional requirement or “shall statement”:
As a system, I need to provide a way to upload xyz files.
Rather than describing what the user needs to accomplish a desired outcome, this story describes what the system must do. Again, we lose the context behind the capability.
More often than not, developers omit the “so that” clause from their user stories. Doing so omits important context about what the user wants to achieve with the resulting functionality. Developers should use that context to help define feature scope and identify larger stories in need of decomposition.
Look what happens to the scope of our original user story when we change the “so that” clause:
Understanding the “so that” helps us ask better questions and tease out details that may change our understanding of a story’s scope. For example, the archival process may actually involve multiple workflow steps:
As stated earlier, acceptance criteria define how we know that the functionality developed to satisfy a particular story achieves intended outcomes. Acceptance criteria help inform development of automated tests and manual test cases which verify that the functionality fulfills functional and non-functional requirements. They also help customers and end users validate that the functionality addresses their business and mission needs.
In keeping with the INVEST criterion of keeping user stories small, and Scrum’s emphasis on breaking up work scope into Sprints, Scrum teams size user stories so they can complete them in a single Sprint. A story that would take longer than a single Sprint to complete is considered an epic.
When development teams routinely fail to finish user stories within a single Sprint, it indicates that they are experiencing difficulty determining how much work they can realistically accomplish within a Sprint. If user stories remain open Sprint after Sprint, the amount of unfinished work eventually overwhelms the team, causing them to miss commitments and deliver lower quality implementations.
It is also common for teams to write user stories that are too small. This usually happens when developers try to specify too many details across a large number of user stories. Since user stories are requirements, make them implementation agnostic. Do not write user stories that include implementation and design details or work tasks.
User stories are a widely used practice in Scrum, despite not being a part of the Scrum framework, because they are useful. They are useful in:
Writing user stories is more of an art than a science. By consistently applying the recommendations and avoiding the mistakes explained here, you will develop an instinct for writing great user stories.
[1] https://agilecheetah.com/handling-non-functional-requirements-in-agile-projects/#User_Story_Acceptance_Criteria, accessed 8/20/2022
Confused about MVPs, MMFs, and MMPs? Time to set things straight.
Table of Contents
Agile software development is an evolving discipline. The authors of the “Agile Manifesto” and its associated “12 Principles of Agile Software” distilled commonalities across a number of Agile approaches into a simple, complete, and cohesive set of values and principles. Defining Agile as a set of values and principles to align to, rather than as a methodology to follow, encouraged creation of new software development approaches and best practices. As long as new approaches and practices align with the Agile Manifesto and 12 Principles, we can consider them Agile. This decentralized approach to Agile adoption democratized Agile, allowing us to adopt existing approaches, tailor them, reject them, or create our own.
Agile theory and practice are firmly rooted in empiricism. Agile shares this characteristic with Lean management and product development. As a result, many Agilists (knowingly or not) have incorporated Lean and product development concepts into Agile approaches.
One of the better known product development influences on current Agile thinking and practice is the concept of the Minimum Valuable Product (MVP). MVPs dovetail nicely with Agile empiricism and value delivery. However, competing definitions of MVPs, as well as popularization of other product development concepts such as Minimum Marketable Features (MMFs) and Minimum Marketable Products (MMPs), have caused confusion across Agile software development efforts. This article explains the definitions of each of these concepts and how they align with Agile software development.
Product development is the process by which product teams bring products to market, from original idea to market release and beyond. Successful products solve problems important to customers in target markets, in ways that satisfy their needs and desires, and at the right price.
An MVP is a simple and quickly produced version of a product that allows product developers to validate their assumptions. MVPs help determine market fit and provide useful feedback that further informs product development.
MVPs are ultimately about lowering risk. The biggest risk in any development effort is building the wrong thing. In the commercial space, this translates into creating something the target market is unwilling to pay for. In organizational IT this risk manifests as system implementations that do not meet the needs of the Stakeholder Community (i.e., sponsors, stakeholders, customers, and end users). Building the wrong thing negates all of the time, effort, and expense spent developing the product.
Continual product validation is baked into Agile approaches such as Scrum. Agile teams continually validate that they are building the right things while verifying (through continuous testing) that they are building them the right way. They also deliver valuable software functionality iteratively and incrementally. Doing so affords development teams multiple opportunities to validate solutions with relevant Stakeholder Community members throughout development. Stakeholder input and lessons learned inform ongoing adaptive planning, requirements definition, design and implementation approaches, and development practices. Use of MVPs to validate solutions aligns with this empirical approach to software development.
The main source of confusion around MVPs has to do with whether an MVP is the first version of a marketable product or a vehicle for validating product assumptions and learning about target markets and customer needs. The first definition seems to align with the word “product” in MVP while the second makes MVPs sound more like prototypes. The root of the problem is that both definitions are correct depending on the type of product and market the product team targets.
Many attribute the coining of the term MVP to Eric Ries. Ries is the author of the 2011 book, “The Lean Startup.” That book popularized the term MVP. However, Ries did not invent the term. That credit goes to Frank Robinson, cofounder and president of Syncdev, a product and marketing development company. He coined the term in 2001 and his company published a white paper in 2008 that defined an MVP as:
The right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.
https://web.archive.org/web/20090105160002/http://www.productdevelopment.com/howitworks/mvp.html, accessed 7/17/2022
Syncdev’s product development approach started with identifying a technically and financially “feasible” product idea. The product team executed product development and marketing strategy in tandem. The high-level product development journey looked like this:
It is important to emphasize that, under Syncdev’s approach, an MVP was the first version of the product. It was the smallest version of a product customers were willing to pay for. This approach was best aligned with selling business-to-business (B2B) or internal IT software systems to specific prospects. It was not conceived for selling commercial products to larger market segments. Those markets were better served by Eric Ries’ definition of the MVP.
Eric Ries defined an MVP as, “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”[1] This type of MVP is primarily focused on finding out what customers need and want based on a set of features most likely to attract paying customers. In this case, an MVP could be a prototype, a mock up, landing page, or “minimal” version of the product. As Ries stated:
As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.
https://libquotes.com/eric-ries/quote/lbq3c8m, accessed 7/17/2022
The objective here is not to develop a product to sell immediately but instead to learn more about customers and their markets while validating customer and product assumptions. As product teams gain knowledge and understanding, they may develop additional MVPs of increasing complexity to test out additional ideas. While an MVP may turn into a sellable product, that is not the focus of this type of MVP.
The Scaled Agile Framework (SAFe) includes a definition of MVP that reads like a hybrid of Robinson’s and Ries’s definitions. It supports validated learning as well as development of a potentially releasable software capability.
As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, SAFe’s version of the MVP is an actual product that can be used by real customers to generate validated learning.
https://www.scaledagileframework.com/epic/, accessed 7/17/2022
In the context of SAFe, an MVP is an early and minimal version of a new product or business solution used to prove or disprove an “epic hypothesis.” Every SAFe epic attempts to validate a set of core assumptions that support its formulation. As depicted in the diagram below:
The SAFe Lean Startup Cycle treats epics as potentially releasable capabilities and aligns budget considerations with MVP development while incorporating validated learning.
Adding to the confusion over MVPs is the concept of MMFs. Mark Denne and Dr. Jane Cleland-Huang introduced this concept in their 2004 book, “Software by Numbers: Low-Risk High Return Development.” They defined an MMF as, “A small, self-contained feature that allows companies to develop the product quickly while still delivering significant value to customers.”[2]
The value of MMFs is that they ensure that development teams deliver value as features. Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users. This contrasts with traditional software systems development which is organized around developing and integrating components. A feature does not need to be user-facing. For example, client systems that communicate with a backend service are that service’s customers. Incrementally developing, updating, and delivering software systems as features aligns with Agile’s iterative and incremental value delivery. You can learn more about the benefits of feature-based development here and here.
An MMF differs from an MVP in that it is a way of delivering value to customers and end users, not a validated learning technique. It is the smallest amount of value we can market to customers and end users. Nevertheless, delivering capabilities as features provides multiple opportunities to validate the product as it is built, deployed, and released, thus supporting Agile empiricism.
Many people use the term MMP interchangeably with MMF. Some describe MMFs as individual features that collectively make up an MMP. Regardless, the idea behind MMPs is to build and release the smallest feature or set of features we can market to customers and end users.
Another school of thought considers an MMP to be the smallest or simplest marketable version of a product resulting from the application of lessons learned from one or more previous MVPs.[3] In other words, after validating product ideas via one or more MVPs, the product team develops a simple marketable version of the product based on previous validated learning.
Every validated learning approach explained in this article emphasizes validating our assumptions about markets, customers, users, and products as quickly and frequently as possible. We do not know how good our product idea is until actual customers and end users get their hands on it. Until then, our assumptions and plans are just guesses / hypotheses in need of validation.
[1] https://leanstartup.co/what-is-an-mvp/, accessed 7/17/2022
[2] https://www.agilealliance.org/glossary/mmf/#q=~(infinite~false~filters~(postType~(~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’mmf))~searchTerm~’~sort~false~sortDirection~’asc~page~1), accessed 7/17/2022
[3] https://www.xdesign.com/blog/minimum-viable-product-vs-minimum-marketable-product-whats-the-difference/, accessed 7/18/2022
Agility combines speed, flexibility, and control
In this video, Frank Velazquez explains how Agile accelerates value delivery.
Many organizational leaders think of Agile as a way to speed up software development, and nothing more. They approach Agile with a traditional project management emphasis on improving efficiency. In doing so, they unwittingly corrupt Agile practices to the point of undermining the very agility they are trying to achieve.
Agile software development teams develop more software functionality faster by focusing on diminishing what Lean terms lead time and cycle time. Agile teams diminish lead time and cycle time by:
The original blog article can be found at:
