Category Archives: User Stories

Video of QASIG Presentation Focused on Managing Quality Debt

I had a great time speaking at the QASIG group meeting last night and met some great folks along with reconnecting with others I haven’t seen in some time. Here is the video of the presentation.

 

Video streaming by Ustream

And the slides

Recognizing Software Debt Talk at Beyond Agile Meeting

A couple days ago I spoke at the Beyond Agile group meeting on the topic of “Recognizing Software Debt”. Early in the presentation we ran an exercise to get a feel for the effects of software debt that was original created by my friend, Masa Maeda. Here is a link to the exercise:

http://www.agilistapm.com/understand-technical-debt-by-playing-a-game/

The exercise went great even though I was using the audience as guinea pigs to run the exercise for my first time. Below is the slide deck that I used as a backdrop for the presentation.

Managing Software Debt in Practice Presentation

Today at the Scrum Gathering in Seattle, I held a session on “Managing Software Debt in Practice” where we got into:

The presentation had too much for the less than 90 minutes that we had for the session. I did not get into scaling Scrum team patterns and heuristics to manage software debt at scale and also less around testing than I’d hoped. Hopefully it was useful for the participants and they got at least one new idea leaving the session. It is difficult to take a 1-day workshop and create a less than 90 minute talk, as I learn again.

Interview: Assessing ROI of Addressing Software Debt

This week, an interview from SearchSoftwareQuality.com with me came out on the book Managing Software Debt: Building for Inevitable Change. The interview has 2 parts. The first is a discussion of software debt and the second focuses on addressing software debt. Here are links to the interview:

Training Schedule 2011

Happy New Year! We are looking forward to a great 2011. We have a great lineup of training planned, including our CSM and CSPO offerings, AgileEVM training, and some new trainings.

New Training Offerings

Along with our current training offerings around Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses, we will also be offering training for:

  • Agile Portfolio and Release Management using AgileEVM
  • Managing Software Debt Workshop (based on our book)
  • Online training and micro-consulting

Although we have been training these unofficially for some time now, these are new official offerings, we are looking for companies and individuals who are interested in taking these courses for a discount. Please let us know if you are interested in test-driving any of these offerings.

CSM and CSPO Training

Lets not forget our CSM and CSPO course listings. You can find a full list of our classes on the Scrum Alliance and on our web site. We will be holding CSM and CSPO classes back-to-back in San Francisco on the following dates:

  • February 15-18
  • March 22-25
  • April 26-29
  • June 14-17
  • August 23-26

Of course, our CSPO course will include introductory training on the use of Innovation Games® to gather data from your customers and stakeholders. We feel strongly that a healthy relationship with your user community and stakeholders is essential to delivering great products.

AgileEVM Training

In fact, we have been working with our customers over the past 6 months on enhancing and improving our own product, AgileEVM. You can take a tour of AgileEVM on our training video page. Please register for a free account today if you don’t already have one. You can manage up to 2 active releases with your free account so please try it out and let us know what you think at AgileEVM Support.

We are looking forward to a great year in 2011. Please let us know if you are interested in our training or consulting services at Sterling Barton.

Our Book is Available: Managing Software Debt – Building for Inevitable Change


I am quite happy about the book that took much of my time over the past couple years has finally come out. Thank you Addison-Wesley for asking me to write a book. Also, I want to thank Jim Highsmith and Alistair Cockburn for accepting the book into their Agile Software Development Series. Finally, I have to thank all of those that have guided, influenced, and supported me over my career and life, with special thanks to my wife and kids who put up with me during the book’s development. My family is truly amazing and I am very lucky to have them!

Focus on Team Communication

In the agile community there are some common practices that are either seen as valuable or to be avoided. Two of those practices are estimation using Planning Poker and Sprint Planning task breakdown. The focus for many teams in these practices is on the estimates themselves and how “accurate” they are. It has been my experience that accuracy in estimates is not possible and belief in their accuracy leads to wasted effort and failure to meet commitments.

Planning Poker

Teams often ask “what if we estimate wrong”. To me this is reality for any estimation process. By definition we are “guessing” (hopefully educated) and therefore our estimates will be wrong. The idea is to be consistent rather than precisely wrong. This allows teams to better predict based upon similar constraints to earlier iteration how much they will be able to deliver in the next iteration. Rather than basing estimates on predictions of the future we are basing them on what we have done in the past.

The use of “estimate size; derive duration” method of estimation helps teams gain knowledge about how much they can deliver in a time-boxed iteration. One technique to generate the estimates of size is Planning Poker. Most teams start out attempting to get the estimate exactly “right”. I will not advocate that this is bad to do but I do think that teams would find Planning Poker and other exercises for estimating size more valuable if they focused on the communication that occurs. The real magic of Planning Poker is that cross-functional team members and team members with different perspectives are able to share their knowledge with each other and ultimately meld the points of view into an approach for implementing a user story. A focus on communication allows teams to capture important information, constraints, and decisions around a particular user story and better understand as a team what is involved in its delivery.

Sprint Planning Task Breakdown

When teams come together for the first time in organizations where they have been separated by functional role or even teams that haven’t worked together before, the act of breaking down user stories into tasks assists teams with communication. If the Product Backlog describes the “what” then the Sprint Backlog describes the “how”. Tasks are tools for capturing the “how” and makes it visible to the entire team. Instead of team members with different functional roles, team members describe how they will contribute to the potentially shippable product increment delivered by the end of the iteration. Instead of focusing on the perfect tasks and estimates on those tasks, I believe it is more valuable to have a shared understanding of how the team will deliver the user story. Tasks are just the tool to make visible that shared understanding and we should focus on the communication between team members and capturing the important details that enable successful delivery.

Now, tasks are not the only way to get a shared understanding, of course. I have been on teams where we would talk, draw a little picture on a post-it note, and then agree with as a team that was enough to plan with. This was with an extremely experienced Scrum team that worked together or around each other for a long time. When a new team comes together in an organization that has not created user stories before they have difficulty getting “right-sized” user stories for the team. Most of the time there seems to be some difficulty breaking them down items into small enough items for the team to deliver within 1/2 of a sprint’s length. As the team does task breakdown they are better able to capture details that help them work out how the whole team will contribute to the user story. This leads to recognition of user stories that are too big or even those that are ambiguous.

New teams using task breakdown in their Sprint Planning meetings should focus on how they communicate with each other and make sure that each member of the team is heard. This will lead to a better shared understanding of how they will work together and deliver successfully.

Focus on Team Communication

Here are some things that teams can do to help their communication in planning:

  • Make sure all team members are heard so they will feel compelled to participate
  • Always discuss reasons why you, as a team member, are not satisfied with the plan
  • Don’t push your estimate or task breakdown suggestions on the entire team
  • Cross-pollinate within your team across functional role boundaries to better understand other roles
  • Use past experiences and story-telling to describe reasons for a particular position
  • Use whiteboards and design techniques to visually portray ideas

Hopefully a focus on team communication will help make estimating and task breakdown a more valuable experience for your team. Please share things that your teams have done to help focus more on communication to increase shared understanding by leaving comments on this blog entry. I look forward to hearing from you.

Slides from Managing Software Debt Talk at PNSQC 2009

Tomorrow at 1:30pm I will be discussing my paper published by the Pacific Northwest Software Quality Conference 2009 in Portland, OR on “Managing Software Debt: Continued Delivery of High Value as Systems Age”. I have uploaded the slides for this presentation and I hope that some of the new content will help those looking for ways to manage their software debt more effectively in 5 key areas:

  • Technical debt: tends to focused on the code and reveals itself in duplication and code smells
  • Quality debt: focuses on QA aspects of software development and shows up in growing bug databases and longer regression test runs
  • Configuration Management debt: focuses on integration and release management aspects and becomes apparent with extreme branching and inability to recreate environments from scratch
  • Design debt: focuses on design constructs of components within an application or enterprise infrastructure and is usually difficult to figure out until you are close to a deadline such handling production load
  • Platform Experience debt: focuses on the people in the software creation process and usually involves extreme specialization and waiting on people to finish their part

Without further ado, here are the slides:

Also, here is the picture I use to discuss Managing Software Debt from high level in terms of maintaining and enhancing value of software assets:

Effect of Managing Software Debt to Preserve Software Value