Archive

Posts Tagged ‘scrum’

The Three Levels of Prioritization. Or, how to eliminate scope creep and always deliver on time.

April 23, 2015 1 comment

tl;dr

The Three Levels of Prioritization:

  1. Must haves
  2. Nice to haves
  3. Wish we could have

——————————————-

I wrote some time ago about Themes in Scrum.  The focus of that blog post was to address the issue of lower priority items in the Sprint backlog.  The idea was to be purposeful in planning around potentially low priority topics such as help and tutorial pages, or documentation.  Click here if you are interested in reading.

Over the years I have learned much about prioritization – both as it applies to backlog grooming, and how it applies more generally. Proper prioritization is the key to keeping your sanity as a Product Manager. The magic of good prioritization:

  1. Forces stakeholders to think about what they truly need and what they can truly live without.
    – the problem isn’t identifying the top priority, it really is identifying priorities 2, 3, 4, and so on.  And most importantly, which items are the lowest priority – which items will not make the cut if push comes to shove.
  2. Sets expectations
    – everything can’t be top priority.  If we agree to work on the top priority items, that means we are not working on the lower ones. At least not right now.
  3. Manages scope and feature creep
    – when new priorities pop up – or stakeholder focus shifts – always ask the question “is this important enough to stop what we are doing now?”.  Or, “if we work on this, what can drop off the list of deliverables?”
  4. Always deliver on time
    – It’s virtually impossible to deliver both a promised set of features AND on a promised delivery date.  However, a hard delivery date can always be met if the feature set is flexible, and the feature set is always flexible in Agile – it is the Product Manager’s job to convince the Stakeholders of this.

How to always deliver on time

After you have forced your stakeholders to think about what they truly need and can truly live without, then managing scope creep and delivering on time are all a simple matter of proper prioritization.  .The first step is to construct a long-term, agile roadmap.   Remembering that in Agile, requirements and priorities can change sprint-to-sprint.  This does not mean you should avoid creating a long-term roadmap, it simply means that it must be constructed in such a way as to maximize flexibility and minimize wasted development cycles.  Use the following three steps to create a flexible, agile, roadmap:

  1. Identify the Minimum Deliverable Feature set
    – sometimes called the MVP – Minimal Viable Product.  If production where shut down unexpectedly, which features would allow the product to still be delivered in some form or another?
  2. Identify dependancies
    – which features provide basic functionality that can be built upon in future iterations, You do not want to start with standalone features that don’t support the broader functionality of the product.
  3. Prioritize the major features into 3 categories:
    • Must haves
    • Nice to haves
    • Wish we could have

While items 1 and 2 deserve attention (maybe in a future post), let us focus on item 3 – the 3 categories for prioritization. Must haves are features that the product can not live without.  These define our MVP.  Nice to haves are features that we would really love to build – features that add real value, maybe features that differentiate our product from the competition – but are not part of the MVP, and at the end of the day, we could deliver without.  Wish we could haves are the “wish list” items. Everybody agrees these features would be great, these features add pizazz and polish to the product, but expectations are low that these will ever be delivered.

The Wish we could have list is the most difficult one to create.  Some might be tempted to put fit-and-finish issues – the polish – into this category.  However, prioritization is dependent on the goals for the product.  Are you trying to simply get to market quickly with an MVP?  Or differentiate your product from the competition with attention to detail?  Apple, for example, would probably consider fit-and-finish as a Must have feature, whereas a start-up company with a brand new technology that just wants to get a foothold in the marketplace might define only basic functionality as the Must haves – fit-and-finish is on the wish list.

With this prioritization scheme in place, it is now easy (relatively) to commit to a delivery date. The commitment date will include all of the Must haves, as many of the Nice to haves as possible, and maybe some of the Wish to haves.  Always schedule time and resources around the Must haves and the Nice to haves. That way, the Must haves will always be delivered.  Unexpected roadblocks might result in some Nice to haves getting dropped, while any overestimations in time or resources allow some of the Wish we could haves to be delivered.

The 3 levels of prioritization as a fractal

To achieve the greatest level of success with this methodology, make sure you apply it to every level of the planning process.  Apply it to the MVP and the high-level roadmap.  Then apply it to the Epics within each major product feature, and again to each User Story within each Epic.  Finally, use the 3 levels in Sprint planning to fill each Sprint with Must have and Nice to have stories.  Time permitting, bring in extra Wish to have stories, or drop Nice to haves when things don’t go quite as planned.  As priorities change over the course of the project, you as the Product Manager can reshuffle what is being worked on without sacrificing the Must have features and stories, and will be able to articulate at any point in the project what is being worked on, what is being delivered, and why.

Autonomy, Mastery, and Purpose. Motivation and the Podular Organization, optimizing for innovation rather than efficiency.

March 27, 2014 Leave a comment

Today I would like to talk about a couple of principles and a couple of books that have had an enormous impact on the way I work.  The first is “Drive – The Surprising Truth About What Motivates Us” by Daniel H Pink, which is a brilliant look at how the “carrots and sticks” motivational techniques of the past are no longer valid and why we need to think about intrinsic – as opposed to extrinsic (external) – motivators.  The 3 pillars of motivation are:

  • Autonomy – the desire to direct our own lives.
  • Mastery – the urge to make progress and get better at something that matters.
  • Purpose – the yearning to do what we do in the service of something larger than ourselves.

The other book I want to talk about deals primarily with the last point – “Purpose”.  Once properly motivated, how do we get everyone in the organization to feel ownership of the business?  The solution is to create a “business within a business”. And this is the subject of “The Connected Company” by Dave Gray where we examine the concept of the podular organization and optimizing for innovation rather than efficiency.

These principles fit in nicely with the basic tenants of Agile – the idea of self-organizing and cross-functional teams.  As with other Agile processes, it seems (although it is not true) that these principles are much more applicable to smaller, leaner, more start-up like companies.  I have seen firsthand how Agile organizations fall back into old Waterfall traps as the organization grows, middle management grows along with it, and communication, motivation, and innovation become secondary to efficiency and predicability.  In a world that increasingly requires people to think creatively, solve problems and remain flexible in uncertain environments, hierarchical, multidivisional organizations and extrinsic motivation just don’t work.  The answer is to build flat organizations around small, self-governing “business within a business” units, or “pods”.

My experience applying these principle has primarily been with Software Develop teams.  While Software development seems particularly suited to these principles, it is left as an exercise for the reader to think about how they might be applied to other business’s such as hardware development, or service organizations.  

Organizing a large company into a series of “business within a business” pods, allows each pod to function as a stand-alone business unit, ideally only answering to its customers.  These customers may be inside or outside the organization, but each pod delivers its own business value thus giving its members real, motivational ownership of the pods success.  This is how a company optimizes for innovation over efficiency.

Within the pod, team members are motivated by the intrinsic value of the units success.  Developers, designers, sales, support – every member of the team must feel ownership of the teams success.  Autonomy and Mastery come into play as each member of the team is encouraged to identify and provide working solutions to the day-to-day challenges of creating success.  The parameters for success become clear, aligned with the goals of the larger business, thus empowering every member of the team.

“The great innovators in business did not succeed on creativity alone,” Gray writes, “their success was a blend of creative thinking and business logic.”

A great article on Fast Company sums it up nicely:

“So if you want to set a context to bring out your teams’ inner Edisons, you need to align their incentives in three ways:

  • Incentives need to breed visible impacts on the business as whole
  • Incentives need to balance short- and long-term thinking
  • Incentives need to reward people for doing what makes the business as a whole more successful and healthier

In this way, a person’s individual work is linked to the collective endeavor. They get personal expression and collective validation. They’re incented to do their best work, for themselves and for the organization.”

 

Creativity comes from the darndest places

So we just finished our first sprint and the team is really energized.  Our velocity for this first sprint was 20 story points.  We used Fibonacci series planning poker to weigh user stories and decided to limit any user to 8 story points or less if it was to be included in the sprint. Anything greater than 8 had to go back into the backlog until it could be split up into smaller stories.  This left us with 5 stories, and a total of 20 points.  I am confident that our velocity will start to dramatically increase in a very short time.  We delivered all 5 stories, btw!

The grooming of the stories in this manner has revealed some interesting trends.  Since the user stories are fairly general, and only define “what” the software needs to do instead of “how” it does it, the development team has far fewer specifications on which to base their solutions.  At first, some team members where hesitant to move ahead without the details they were accustomed to in their past waterfall projects.  As Product Owner, I made sure the team knew that I trusted – and in fact was counting on – their creativity.  When a team member was not sure how I wanted a particular user story implemented, I would say something like “I don’t care how you do it.  Give me a couple of suggestions of how you would do it.”

It quickly became obvious that the developers were coming up with solutions that were far more clever than I or any Product Manager could have, and they were also taking into consideration far more of the long and short term ramifications of those solutions.  One of the devs said to me, “Man, the backend architecture is really going to require a lot of rework,” and then proceded to outline his solution and how he would implement it.  It was a very elagent solution.  “I hope we get this solved in time, some of the tasks in this sprint are dependent on it” he said.  To which I replied, “Even with your help, if I had gone off fully speced a backend solution myself, it would have taken me weeks.  And then I would have come back with a design for you to implement that probably wasn’t very flexible, and would have delayed the rest of the project.  By telling you what I needed instead of telling you what to do, you just solved the problem far more elegantly, and it’s only the 2nd day of the sprint!”

If  you trust the people who know the problem to solve the problem, the solutions start to flow like water.

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.

%d bloggers like this: