Archive

Archive for April, 2012

Backlog Grooming

April 27, 2012 1 comment

I have been spending a lot of time this week – as you might imagine – grooming the ol’ Backlog.  I have been focusing on both the set of user stories for the upcoming sprint, as well as the longer term release schedule.  It is becoming increasingly important to look down the road and flesh out and prioritize the tasks and features we most need in our next release.  At our current sprint size of 2 weeks, we have a total of 12 sprints until we deliver the next public release.

Angela Druckman on the Scrum Alliance site, talks about backlog grooming:

Sometimes called StoryTime sessions, the purpose of these meetings is to make improvements to the Product Backlog.  That definition is deliberately vague because the meeting is quite versatile.  A Backlog Grooming session can be used to:
• Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more StoryTime sessions)
• Break down user stories that are too big (epics)
• Improve user stories that are poorly written
• Estimate backlog items
• Add acceptance criteria
• Look deeper into the backlog to do longer-range technical planning

That last bullet is an important one.  Some people mistakenly believe that doing Scrum means never focusing on anything but what is coming up in the next sprint.  This is not true.  Instead, backlog grooming sessions are a great place for a Product Owner to say “The March release is coming along great, so today I would like to spend time looking at the user stories I hope to get in the July release.”  Doing this gives teams an opportunity to look further into the future of the product, and can alert them to technical challenges and “gotcha’s”.

For the entire article, click below:

How to Hold Effective Backlog Grooming Session

Themes in Scrum

April 18, 2012 1 comment

There is considerable discussion among Scrum practitioners on the subject of themes.  Sprints often have a theme, which is more akin to a goal.  User Stories are also quite often organized into themes to help with managing the overall progress of a project.  Id like to look at User Story themes a little more closely.

One issue that I foresee in our own evolving scrum process is that certain types of projects may not ever bubble their way up into a sprint.  For instance, features and UX may often seem to deliver the highest Business value, while refactoring and documentation may be viewed as important – even essential – yet never quite deliver the business value when compared to other more visible projects.  The situation reminds me of the old sports adage, “Second place is the first loser.”  The point here is, how do we make sure that our sprints address a wide range of topics, and don’t get overly focused on only the highest priority items?

As an example, an epic user story describing a rich product feature that delivers a great deal of tangible business value is decomposed into perhaps a dozen smaller user stories of decreasing business value.  The highest value stories are the ones that deliver the minimal marketable, or minimal usable feature set, and their associated validation processes.  Next in line might be features that are essential to a finished and professional product, followed by “nice to have” features.  Finally, if we are smart enough, we have added stories for documentation and help, sales support, or even training.

So, what happens when we complete a sprint or two and deliver the highest value subset of stories and now start planning the next sprint?  Well, there is a very good chance that other high value features are in the backlog that trump the remaining stories in our first feature set.  Now, our goal may very well be to deliver as may minimally viable features as we can, which is a fine goal.  However, were does this leave the “nice to have’s”?  The documentation and sales support?  It would be nice if we could prioritize these before we forget everything that went into building the higher value stories.

I think the solution is to create themes for the user stories and commit to adding stories from all themes into sprints as appropriate. For example, maybe documentation and help is only 25% as valuable as the major features of the product.  Now, we clearly don’t want to neglect the high value features, after all, customers don’t buy a product because it has good help screens.  However, customers do stay with a product and tell their peers about it when it is polished and the user experience is great – so we don’t want to neglect these features either.

What I propose is that the Product Owner commit to organizing the backlog into Themes that allow some of the lower relative value items to be addressed on a periodic basis.  For instance, in our example above, we determined that documentation and help generally had business values around 25% of that of the highest value feature stories.  Then the team should commit to addressing stories in this “theme” once every four sprints.  In other words, the goal of every 4th sprint should be to focus on documentation and help themed stories.  That way, the highest value items always get the highest amount of attention, but 2nd, 3rd, and 4th place see a little action, too.

Here are some suggested themes that I think might work for our specific sprints:

  • Major user functionality
  • User experience (UX)
  • “Nice to have” features and product polish
  • API’s
  • Documentation and Help
  • Training and Sales support
  • Marketing support
  • Back end architecture and Data Modeling
  • Refactoring

This list is very much off the top of my head, but I am sure it could be fine tuned.

Let’s review the basic tenants of Agile and Scrum

April 9, 2012 Leave a comment

This week our Scrum Masters are at Scrum Master training.  In two weeks, I go to Scrum Product Owner training.  I thought this would be a good time to re-iterate the Agile Manifesto:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools 
  • Working software over comprehensive documentation 
  • Customer collaboration over contract negotiation 
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left
more.

Principles behind the Agile Manifesto

  1.  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

In the following weeks we plan to put these ideas to work.  It wont be easy.  Ill let you know how it goes…

The Power of Small Batches in Software Development

April 3, 2012 Leave a comment

As our company moves forward with implementing Scrum, it’s good I think, to review what it is we are trying to fix, and what it is we are hoping to accomplish. Our legacy processes have been plagued with classic waterfall problems.

  1.  Long release cycles
  2. Massive, often difficult to manage, complexity to the product.  Features are difficult to test and document.
  3. Development resources are “Interruptable”.
  4. Progress is often measured by “Vanity Metrics”
  5. There is little flexibility or creativity once the process has started

Committing to 2 Scrum teams, and (initially) 2 week sprints has forced the team to begin an effort of breaking down the product, and the product features, into smaller and smaller pieces. Maintaining this list will be my primary responsibility as Scrum Product Owner. The advantages of breaking down the product onto digestible pieces is quickly becoming obvious;
The incremental releases will give us more opportunities to put working features in front of customers earlier and more often.

The smaller feature sets will be easier to test.

The team can better manage the amount of time team members spend on “firefighting” tasks such as support and operations.

As the team moves from sprint to sprint we will be able to judge and predict our capacity with considerably more accuracy – thereby cutting back considerably on over promising, or under delivering.

The team will have much flexibility to change coarse in response to feedback from customers and stakeholders.

The teams progress can be measured against real deliverables.

Limitations of Written documents

April 2, 2012 Leave a comment

From Jeff Sutherland’s “Scrum Handbook”

“A written document is an incomplete picture of my ideas; when you read it, you create another abstraction, which is now two steps away from what I think I meant to say at that time.”

I think I will have a hard time convincing my management to get rid of written specs completely, but thinking of them in terms of abstraction layers is increadibly useful.

Welcome to Intelligent Product Design

April 2, 2012 Leave a comment

This should be an interesting  journey.  I find myself in the unique position of re-joining a development team on a product that I helped create nearly 10 years ago.  The product has come a long way since I left the original team about 5 years ago.  The original company has been acquired twice since I left and now enjoys some very substantial and significant corporate support.  This blog is intended to chronicle my experiences as the new Product Manager and Agile Scrum Product Owner.

The company is newly dedicated to Agile and Scrum, but my intentions are to also apply Lean methodologies and other related techniques such as Customer Development, Minimal Viable Product, and the Build-Measure-Learn cycle as described by Eric Ries, Steven Blank, and others.  Paraphrasing from “The Innovators Dilemma” by Clyton Christensen:

  • Corporations are very good at creating incremental improvements to existing products and serving existing customers – sustained innovation – but struggle to create breakthrough new products – disruptive innovation – that can create new sustainable sources of growth.

So, hopefully I can get some comments and  lively conversation here as we attempt to break the stereotypical corporate development cycle and inject some real Entrepreneurial spirit into this effort!

-Brad Reeves

%d bloggers like this: