You’re so excited to finally have insights into issues that have plagued you. With great expectations, you present your results and then:

Crickets…

A novel heat grid can really capture attention

Sometimes, the problem isn’t your data, it’s the packaging.

We’ve evolved to notice new things or changes in our environment. This is how our ancestors saw the lion, tiger, or bear before it got them.

Today, this is how we notice the car that’s suddenly veering into our lane or quickly stopping in front of us.

Problem is, most data is presented in the same old boring graphs or tables; nothing new there!

Novel visuals attract our attention, just like lions, tigers, or bears. Our brains are hard wired to notice things that are new or changed.

We’re also visual. When data can be processed visually, we’re more likely to dig into the details and relationships, or at least get the gist of it all more quickly.

A visual presentation that’s new to your audience is the perfect “bright and shiny object” to capture attention and draw people into your content.

I’ve used this idea to shift the focus of conversation across large organizations.

For example, introducing a new way to visualize project status can get people looking at things more deeply or from a new perspective.

Using this new visual for regular project reporting, can move conversations in a more productive direction, permanently.

A word of caution, a useful visual is very different from chart junk. What you need is a visual that makes the information easier to process. Your visual has to help people understand the data and ideally, be unique enough to attract attention.

But shouldn’t a good idea just stand on it’s own? Well yes, but every idea gets packaged. Good ideas in bland, ugly, or hard to consume packages are often ignored.

Some might worry about “tricking” others into digging into their data, but in today’s world, you have a lot to overcome. Smart phones, tablets, and laptops are everywhere. Sometimes your participants need a jolt to see anything. So don’t be shy about using every trick at your disposal.

So pull your audience into your content, spice up your data, and kill the crickets with an unusual visual presentation.

I’ve used is a heat grid like the one shown above with great results. Try it yourself: heat grid generator.

If you havent’s heard of Keep Austin Agile, it’s a one day agile conference that’s put on every other year.  Next time is March 21st, 2014.  I highly recommend this conference, as the cost is low, the content is great, and the attendee vibe is inspiring.

Are You Compromising Your Product Owner?

The Product Owner role is key to creation of software that users value. It’s also the most compromised role in Scrum – organizationally, politically, and functionally. From political appointments to part-time assignments to lack of stakeholder support, there’s lots that can go wrong. In this highly interactive session, you will learn how to select, on-board, and support your Product Owner by solving real-world problems and removing constraints placed on this critical role.

We’ll cover three key stages in the life of a Product Owner:

1. Selecting a Product Owner
2. On-boarding a Product Owner
3. Supporting a Product Owner

No single person controls all of those phases, so we’ll show you how to use influence and education to achieve your objective, no matter what your role.

This session is highly interactive, requiring participants to work as a team with provided materials through several real world problems in each of the key areas.

In this session, you will learn:

• How the larger organization and type of software impacts the Product Owner role.
• How to sell stakeholders and management on the importance of the Product Owner role.
• How to set expectations so the right product owner is chosen and is available to the team.
• How to get a new Product Owner up to speed quickly.
• How to gel a Product Owner and Scrum Team into a working whole.
• How to get multiple stakeholders to agree on backlog priorities.
• How the Scrum Master, Team, management, and stakeholders support the Product Owner.
• How to handle turnover in the Product Owner role.
• How to handle a series of different Product Owners when required by your business.
• How to work with a <gasp> real customer as your Product Owner.

Time is reserved for debrief and questions/answers at the end of the session.
(edit: links removed as Keep Austin Agile 2014 page was taken down)

It’s hard to imagine a completely prioritized backlog when you’re just getting started.  It can seem like an almost impossible task.

Relax, first you need to take a trip to MoSCoW!

What is MoSCoW?

OK, we’re not talking about a trip to Russia.

The MoSCoW method is a way to group your user stories into high-level priority buckets.

MoSCoW comes from:

Must: a user story that, if missing from the project, would make the project unsuccessful.

Should: a high priority user story that is important, but it’s absence won’t kill the product.

Could: a nice to have user story that you’d clearly sacrifice for a should or must.

Won’t: a feature that is explicitly excluded from the project.

The two o’s in MoSCoW are just added so we have an easy way to remember and talk about the method.

Many project management frameworks have a four quadrant prioritization scheme.  I like MoSCoW because of the simplicity and clarity of Must, Should, Could, and Won’t.

Why should I care about the MoSCoW method?

First, it facilitates a high level discussion with users about the relative business value of each user story.

Second, it gives you an easy way to coarsely prioritize user stories at the start of a project.

Third, it clarifies feature priority so the team knows which features can be dropped if necessary to maintain quality and schedule.

Fourth, it helps you prioritize new user stories as they are discovered.

Fifth, you’ve gotta just love the won’t, which gives you a great reminder about the features you’ve decided not to implement.

Finally, it’s just fun to have a catchy name like MoSCoW.

When should I use MoSCoW prioritization?

Personally, I like MoSCoW best at the very start of a project.  It allows you to create a high level overview with users and other stakeholders.

Later, as new user stories are discovered, you can use MoSCoW as the first step to set the priority.

You can also use MoSCoW to work through any changes desired later in the project.

How do I get started prioritizing my backlog using MoSCoW?

When creating a backlog, I like to start in analog mode, using index cards or sticky notes.

This lets you quickly write out the epics, trash them, write new ones, move them around, and discuss them in a group setting (assuming co-location).

Whenever possible, find a room and set aside plenty of time to immerse in the MoSCoW process with your users.

Wait, this can’t possibly work, users will just say everything’s a Must

True enough, the first time users go through this process they’ll want to make everything a must.

The 80/20 rule tells us that 80% of users only use 20% of the features. So, in general, the first focus is on the most used 20% and the other 80% less used features are best spread across should, could, and won’t.

Implementing all the “80% features” is a *huge* waste. That’s what we’re trying to avoid.

You’ll want a healthy number of should and could stories because this gives you flexibility later in the project. This flexibility allows you to defer or drop less important user stories so you can make your schedule and maintain quality.

But MoSCoW doesn’t help because every user story needs to be prioritized

Sure, you’ll eventually need all user stories in the backlog prioritized, but you only need enough user stories prioritized, detailed, and sized to keep the team productive.

Think of MoSCoW as a first step. It just gets the user stories into the high level buckets of must, should, could, and won’t.

Next, you can pull the highest priority must user stories to the top of the list. The team will start working on the first few must stories, so prioritizing the remaining stories can wait a bit.

If you prioritize the entire backlog at the start of a project, you’ll probably end up wasting time. Priorities change as you learn, so don’t get too far ahead of the team.

MoSCoW won’t fit in with my online tool, it just wants an ordered list of user stories

In your tool, you can add  must, should, could or won’t to each user story’s title or description field.  This way, you don’t lose track of the MoSCoW bucket each user story was put in.

User story titles might look something like this:

Must:  As a user, I want to login to the system so I feel like my personal information is secure.

Summary

So get the backlog prioritization started the easy way, take that trip to MoSCoW.

It’s just four easy buckets of must, should, could, and won’t, but it will take you a good ways towards prioritizing your backlog.

MoSCoW will also give you a good high-level perspective for more productive discussion, make your initial prioritization easier, and give your team well defined flexibility on features.

Have you used MoSCoW prioritization?  Do you have a question or feedback?  Speak your mind with a comment!

Kirsten has a quiz that identifies your personal productivity style, which allows you to understand how to work WITH your personality traits to organize your life.

Makes sense to me.  Why wouldn’t you want to organize your day in a way that works best for your personality?

Is it possible that you’ve been trying to organize your work in a way that is terrific for someone else, but horrible for you?

Who knows?  Take the quiz (link removed, site gone) and find out.

I’m “The Fantastical” (visual thinker), leave a comment and tell me your result and whether the info was helpful for you.