The Importance of Managing Work in Progress (WIP) in Scrum Projects

A OR B - SG - v171204 (FOR BLOG) lowerres

Take a look at the results at the end of a sprint on a Scrum project. There are two scenarios. Both have the same user stories with the same story points for each:

  • User story 1: 13 story points
  • User story 2: 8 story points
  • User story 3: 3 story points
  • User story 4: 5 story points
  • User story 5: 1 story point
  • User story 6: 3 story points
  • User story 7: 1 story point

Scenario A

A OR B (A) - SG - v171204 lowerres

Here are some details on A:

  • User story 1: 70 hours of work performed, 5 hours of work remaining
  • User story 2: 51 hours of work performed, no work remaining (and it meets the Definition of Done [DoD])
  • User story 3: 45 hours of work performed, 13 hours of work remaining
  • User story 4: 29 hours of work performed, no work remaining (and it meets the DoD)
  • User story 5: 3 hours of work performed, 2 hours of work remaining
  • User story 6: 30 hours of work performed, 17 hours of work remaining
  • User story 7: 4 hours of work performed, 1 hour of work remaining

A is summarized as:

  • 232 hours of work was performed, and 38 hours of work remains
  • 2 user stories were done, and 5 user stories were not completed

Scenario B

A OR B (B) - SG - v171204 lowerres

Here are some details on B:

  • User story 1: 75 hours of work performed, no work remaining (and it meets the DoD)
  • User story 2: 51 hours of work performed, no work remaining (and it meets the DoD)
  • User story 3: 58 hours of work performed, no work remaining (and it meets the DoD)
  • User story 4: 29 hours of work performed, no work remaining (and it meets the DoD)
  • User story 5: 5 hours of work performed, no work remaining (and it meets the DoD)
  • User story 6: 14 hours of work performed, 33 hours of work remaining
  • User story 5: no work performed, and five hours of work remaining

B is summarized as:

  • 232 hours of work was performed, and 38 hours of work remains
  • 5 user stories were done, and 2 user stories were not completed

What Counts

A OR B (CONCLUSION) - SG - v171204 lowerres

Scrum requires teams to build an increment of functionality during every sprint. Only work meeting the Definition of Done (DoD) is counted as complete, demonstrated at the sprint review meeting, and is potentially shippable.

There were two scenarios. Both had the same user stories with the same story points for each, and the same amount of work hours performed. Yet the outcomes were dramatically different. In A, 2 user stories were done--and are to be demonstrated at the sprint review meeting, and are potentially shippable. In B, 5 user stories were done--and are to be demonstrated at the sprint review meeting, and are potentially shippable. B is the better scenario.

A possible explanation for the differences between the two situations is that the Scrum team in B may have done a better job of limiting Work in Progress.

To learn more about agile/Scrum, check out the award-winning book, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. You're invited to visit the digital press kit, watch the trailer, and pick up a copy of the publication—it’s available in paperback and ebook—at Amazon.

*****

You're invited to connect with Scott M. Graffius on social. Like his page on
Facebook, follow him on Twitter, and connect with him on LinkedIn.

Scott presents thought leadership on project, program, portfolio, and PMO management related topics of timely importance. He delivers talks at private and public events in the United States and internationally. For information on availability, fees, pro bono work and more, visit
SpeakerHub.

For more information, you can visit Scott's personal
website, review his bio, and read additional stories in the blog. The websites for his business and award-winning book are http://Exceptional-PMO.com and https://AgileScrumGuide.com.





custom - back to main page of blog

Are Agile and Scrum Limited to Technology Projects or Technology Industries?

1 - twitter - tech non-tech both - SG - v180331B LOWERRES

Shifting customer needs are common in today's marketplace. Businesses must be adaptive and responsive to change while delivering an exceptional customer experience to be competitive. Traditional development and delivery frameworks are often ineffective. In contrast, Scrum is a value-driven agile approach which incorporates adjustments based on regular and repeated customer and stakeholder feedback. And Scrum's built-in rapid response to change leads to substantial benefits such as fast time-to-market, higher satisfaction, and continuous improvement—which supports innovation and drives competitive advantage.

Agile and Scrum were once the sole domain of software development. However, the benefits and results have not gone unnoticed by others. Practices are being adopted by additional departments and industries. Examples follow.

  • The State of Scrum Report(1) revealed that 21% of Scrum projects are run by departments outside of Technology such as Marketing, Finance, and Sales.
  • An article published in The New York Times(2) noted agile's use in diverse industries—with examples ranging from a museum in Sydney, Australia, to an automobile dealership in Maine.
  • A business brief(3) illustrated how varied businesses—including John Deere, NPR, and Mission Bell Winery—employed agile.

In summary, agile and Scrum are used broadly. For more information on agile/Scrum, pick up a copy of the award-winning book,
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. For more information on the publication, and to connect:


References:

(1) Scrum Alliance (2017). The State of Scrum Report. Westminster, CO: Scrum Alliance, Inc.
(2) Hardy, Q. (2016, November 25). "The New Workplace is Agile, and Nonstop. Can You Keep Up?" The New York Times, page B1.
(3) Rigby, D. K., Berez, S., Caimi, G., and Noble, A. (2016).
Bain Brief: Agile Innovation. Boston, MA: Bain & Company.

*****

You're invited to connect with Scott M. Graffius on social. Like his page on
Facebook, follow him on Twitter, and connect with him on LinkedIn.

Scott presents thought leadership on project, program, portfolio, and PMO management related topics of timely importance. He delivers talks at private and public events in the United States and internationally. For information on availability, fees, pro bono work and more, visit
SpeakerHub.

For more information, you can visit Scott's personal
website, review his bio, and read additional stories in the blog. The websites for his business and award-winning book are http://Exceptional-PMO.com and https://AgileScrumGuide.com.





custom - back to main page of blog

Produce Planning Cards™ — A Relative Estimation Tool and Technique for Agile Teams

Scott M. Graffius is the Founder and CEO of Exceptional PPM and PMO Solutions™, and the author of Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. This post shares news related to the business and the book.

Exceptional PPM and PMO Solutions™ introduced Produce Planning Cards™ to help agile teams estimate work. An overview of the tool and the technique is provided in a video presented by Agile Scrum and Exceptional PPM and PMO Solutions™. It's available at https://vimeo.com/261680776, and it can be played below.

Produce Planning Cards™ Help Agile Teams Estimate Work from Scott Graffius on Vimeo.


For more information on the Produce Planning Cards™, visit
http://exceptional-pmo.com/Produce-Planning-Cards.

*****

You're invited to connect with Scott M. Graffius on social. Like his page on
Facebook, follow him on Twitter, and connect with him on LinkedIn.

Scott presents thought leadership on project, program, portfolio, and PMO management related topics of timely importance. He delivers talks at private and public events in the United States and internationally. For information on availability, fees, pro bono work and more, visit
SpeakerHub.

For more information, you can visit Scott's personal
website, review his bio, and read additional stories in the blog. The websites for his business and award-winning book are http://Exceptional-PMO.com and https://AgileScrumGuide.com.






custom - back to main page of blog

Potentially Shippable Product Increment and Minimum Viable Product Approach

Potentially Shippable Product Increment

1 - Prod Incr - SG - v170924B LOWRES

Scrum requires teams to build an increment of functionality during every sprint, and the increment must be potentially shippable because the Product Owner might decide to release it at the end of the sprint.

  • The product increment is the sum of all backlog items completed during the current sprint
  • Potentially shippable is defined by a state of confidence or readiness
  • Shipping is a business decision: Shipping may or may not occur at the end of the sprint (new functionality may be accumulated via multiple sprints before being shipped)

Minimum Viable Product Approach

1 - MVP vB - SG - v171204 LOWRES

The product increment may or may not be marketable. However, a Minimum Viable Product (MVP) approach is sometimes used to help test marketable ideas. MVP is a product release strategy which can be used in Scrum (or another framework). The term was created by Frank Robinson, and popularized by Steve Blank, and Eric Ries.

The MVP has just those features (functional, reliable and usable) considered sufficient for it to be of value to customers, and allow for it to be shipped or sold to early adopters. Customer feedback will inform future development of the product.

Here are a few examples of then-startups use of an MVP:

  • Facebook: The first product (originally called Thefacebook) tested traction of students connecting with their college/class and posting messages. Other features—built on the initial success—came later.
  • Groupon: It launched with a WordPress site and PDFs emailed to early subscribers. The test proved successful, and the company subsequently built its voucher system and backend.
  • Spotify: The initial product was simple desktop app, tested in a closed beta. The MVP proved to be of interest to consumers, and more features followed.

*****

This article includes excerpts from the award-winning book,
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions, available in paperback and ebook formats at Amazon. For more on the book, visit agilescrumguide.com.

*****

You're invited to connect with Scott M. Graffius on social. Like his page on
Facebook, follow him on Twitter, and connect with him on LinkedIn.

Scott presents thought leadership on project, program, portfolio, and PMO management related topics of timely importance. He delivers talks at private and public events in the United States and internationally. For information on availability, fees, pro bono work and more, visit
SpeakerHub.

For more information, you can visit Scott's personal
website, review his bio, and read additional stories in the blog. The websites for his business and award-winning book are http://Exceptional-PMO.com and https://AgileScrumGuide.com.






custom - back to main page of blog

Product Backlog Ordering Technique: Factoring Business Value and Risk

1 Twitter - Ordering Backlog - SG - v1180113 LOWRES

Scrum is the most popular agile project development and delivery framework. In Scrum, the product release backlog (sometimes referred to as the product backlog) is a list of features, user stories, bugs to be fixed, and/or other requirements. The Product Owner is the ultimate holder of the backlog. The Product Owner prioritizes items, and different methods can be employed to help accomplish that work. This brief article focuses on the technique of factoring business value and risk.

Each item in the product release backlog would be rated as either high or low in two dimensions: business value and risk. It is suggested that high business value, high-risk items are worked on first. While that may seem counterintuitive, the earlier this work is done, the sooner the team will move to mitigate the issues and unknowns—leading to a higher quality product. If there's a failure, it will occur early and relatively inexpensively.

An ordering of priorities is illustrated above, and it follows:

1. High business value, high risk.
2. High business value, low risk.
3. Low business value, low risk.
4. Low business value, high risk.

Alternatively, other prioritization methods—such as the MoSCoW ranking model— may be used. MoSCoW will be highlighted in a subsequent article.

This content is an abridged excerpt from the award-winning book,
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions, available in paperback and ebook formats at Amazon. For more on the book, visit agilescrumguide.com.

*****

You're invited to connect with Scott M. Graffius on social. Like his page on
Facebook, follow him on Twitter, and connect with him on LinkedIn.

Scott presents thought leadership on project, program, portfolio, and PMO management related topics of timely importance. He delivers talks at private and public events in the United States and internationally. For information on availability, fees, pro bono work and more, visit
SpeakerHub.

For more information, you can visit Scott's personal
website, review his bio, and read additional stories in the blog. The websites for his business and award-winning book are http://Exceptional-PMO.com and https://AgileScrumGuide.com.





custom - back to main page of blog