Skip to main content

Author: Robert Galen

Grooming, Maintaining, or Refining your Backlogs – Practices for Success, part-1

In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition . In both books I took on the topic of Backlog Grooming.

As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog

Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.

Backlogs & Refinement

Why don’t we first start with a definition of Product Backlog. From the July 2013 Scrum Guide, I’ve captured the following:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. 


A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. 


The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

And because this article is about Backlog Refinement, let’s see what the Scrum Guide has to say about it as well:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

Now that we’ve explored what a Product Backlog and Refinement is, by process definition, let me share some of my experiences around effective refinement.

12 Tips for Effective Backlog Refinement

  1. Regularly Scheduled Refinement Meetings – I’m a big fan of creating a tempo of regularly scheduled Backlog Refinement meetings within your teams. I usually schedule 1-2 of them a week for an hour each. The entire team is invited and expected to attend. I want everyone to come to the meeting “backlog aware”, that is, they’ve looked at likely refinement candidates before the meeting AND they have thoughts surrounding (size, ordering, design, dependencies, strategy, quality, risks, and optimal flow).

    I also recommend that a team member take detailed notes that capture the valuable discussions and next-step decisions that are made. This is invaluable information and you don’t want to lose it. I normally ask members to round-robin note keeping, which helps to keep everyone engaged in the meeting, and in the backlog.

  2. Rigorous Prioritization – You must truly reinforce the notion of order or priority in your backlogs. I think of the Highlander movies and the phrase – “There can be only One” in this regard, so please don’t overload priorities

    From my perspective there are a variety of factors that should influence priority:

    • Customer value (right problem solved)
    • Business value (revenue generated)
    • Technical value (fosters learning, reduces risk, solid solutions, intelligent workflow)
    • Quality value (mitigated risk or improves quality)
  3. And I look for the team to consider and balance against all of these variables when setting priority. For example, it should never be the case that customer value always drives prioritization without consideration of technically sound solutions.

  1. Examine Your Stories Frequently – I often encounter teams who only refine their stories once. In that context they write them, refine the wording, write acceptance tests, estimate them, and order them – all at the same time. I could see doing that for trivial or straightforward stories, but never for complex ones.

    I much prefer an approach where the team “samples” the stories over several refinement meetings. Taking the story from concept or idea (Epic) and methodically breaking it down into refined and executable stories. I sometimes recommend to teams that—a “good story” should be refined a minimum of 3-4 times during its evolutionary lifetime. And this includes sufficient space in between refinement discussions so that the team has time to think about the story in relation to all of their other work and the project and product goals.

  2. Egg Timer – I usually recommend that teams stay aware of their story refinement velocity, that is, how many stories do they discuss in a 1-hour meeting. I often see velocities of 1-2-3 stories, which to me implies over –discussion. I prefer the team have a goal of “advancing” stories in their refinement meetings and not necessarily complete them in one sitting.

    The real point of a backlog refinement meeting is not to complete stories as quickly as possible, but to advance the understanding and clarity around the stories. As long as the team makes progress, and keeps chipping away at the stories, I’m happy with their progress. You might ask, what is a fair or rough velocity goal? I’m not sure there’s a magic number, but refining a story every 5-6 minutes might be a reasonable goal—so perhaps 10-12 per 1-hour meeting.

  3. The Estimates are NOT the most important thing – We’re in the middle of a refinement meeting and leveraging Planning Poker as a means of collaborative estimation. In one case, 2 developers have been debating whether the story is 5 or 8 points in size for the last 30 minutes. Eventually, the Scrum Master has to move on and the team still hasn’t agreed on the estimate. In another case, the testers on the team think a story is 13 points, but the developers strongly disagree. And the story ends up being estimated at 3 points. After this happens a few times, the testers disengage in the estimation and simply acquiesce to the developers on all estimates.

    In both cases, the estimates (numbers) have been the focus point of the team. I strongly would argue that the estimates are much less valuable than the DISCUSSION that the process of Planning Poker estimate enables.

    Who cares if it’s a 5 vs. an 8? At the end of the day, pick a reasonable, relative value and move on. BUT, have rich, deep, collaborative discussions across the team about the story. Hear everyone’s experience. Hear their concerns. Listen to what’s said and unsaid. And as a team, come to a fair and balanced relative estimate for “all the work” to move the story to meet your Definition of Done. That’s the value that the estimates drive.

Wrapping Up

I hope I’ve established some baseline thinking on your part regarding the practice of Backlog Refinement. From my perspective, it’s much more than simply developing agile requirement lists. It’s also the planning and strategy part of agile execution and it makes all the difference in how well your sprints are delivered.

In the next post, I’ll finish delivering tips 6-12 and wrap-up this topic. I hope you “tune in” for the remaining tips, until then…

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Splitting Stories – What do you mean you’re Not Done?

I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…

Original Question

I have a serious case of “I want to get back to JIRA Agile”.

My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.

Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.

Acceptance Criteria:

  • Total backlog story points stays true
  • Velocity of previous sprint stays true (commitment is reflected accurately)
  • It’s not adding a huge amount of overhead on the ScrumMaster or the person doing it
  • It doesn’t need a custom app for doing this

Looking forward to your feedback!

Reply #1
A slight modification on the above. We split the story (which actually creates a parent and another child) then Rally will automatically split the completed and incomplete tasks. Then, and very important, set the Unfinished story points to 0. Rally assigns the original points to each sibling. This will create the illusion of a greater velocity that actual. Some people allocate the points, but I am of the opinion “Done or Not Done” (There is no Try!) 

Mark the Unfinished story as Complete but not Accepted. Then when the Continued sibling is complete and accepted, go back and accept the unfinished sibling. This way the Feature %done is accurate. I suspect that the parent is not counted in the story count, but I’d have to check.

Reply #2
This is a tough one. Rally’s splitting solution is a good idea for other things, but there is always a trade off with the implementation for rolling over stories from sprint to sprint. Two stories are created with identical points under an epic, and any project scope reports are doubled. If you make the story zero points, you still need to mess with the state to ensure it does not impact feature stats. Until rally creates a way that a story was “historically” in sprint 1 and is now in sprint 2 ( as the same story) you will need to make trade offs.

I typically just move the story forward because I am mostly concerned about work completed, not what was not accepted after the sprint is closed. I find the need to know what was in a missed by the team is only valuable for the retrospective. Not beyond. I keep an external spreadsheet of committed vs earned points outside of Rally for stats only so the team can see if they constantly over/under commit. Not story rehashing.

Reactions

My first reaction is how a tool, any tool, can take over the conversations within agile teams. Here the functionality of the tool is driving much of the thinking of three leaders within their respective agile team contexts.

They also seem to be worrying a great deal about the “reporting”. Are they fairly representing the velocity/points and will observers get the “right” impression from examining the trends?

This is an example of why I don’t like “leading with” tools in the first place. Instead of focusing on effective agile principles and practices, we end up worrying too much about the tool and the data reporting.

How I handle un-Done Work

I know this may be a little severe, but I’ll share with you how I like to handle un-done work. I’ve been doing it this way for 10+ years. Don’t necessarily know where or when I started it nor who influenced me in this direction. I think it’s what’s recommended in most basic agile project management books, but I don’t have a solid reference off the top of my head.

Here we go:

  1. IF a User Story isn’t complete (to a team’s Definition of Done) then they get NO CREDIT for any of the story points in the current sprint
  2. IF the Product Owner decides the story warrants it, it will move to the next sprint (complete it OR remove it)
  3. In their Retrospective, the team discusses how to get better at committing to realistic goals and finishing their work
  4. In Sprint Planning, the team plans the remaining work to cleanup or finish the story
  5. When the story is complete in the next sprint, the team realizes all of the story points

Basically this model reinforces the notions of:

  • Team receives no partial credit for incomplete work
  • Team commits to a body of work within a sprint and delivers it (or more)
  • Team makes their work and dynamics transparent
  • Team strives for continuous improvement

As I try to influence each team towards base agile principles. And yes, I understand that most agile tools struggle with this notion. They typically want to “split” the story from an “accounting” perspective.

Arguments

I always receive arguments about this approach.

First and foremost is the affect it has on team velocity. Clearly if a team has an average velocity of 25 and misses an 8 point story then their velocity might be 17 points and then 33 points in subsequent sprints. This “turbulence” will be clearly visible to everyone and will probably cause uncomfortable conversations. It’s ugly. It makes stakeholders pay attention. It makes predictability and forecasting hard.

Exactly!

Another argument is that the team will become demoralized.

Why? They clearly struggled a bit with this story and need to reevaluate their estimation and work planning. So what? That happens with newer teams and this event will create healthy discussions and adjustments in their retrospectives.

From my perspective, it all boils down to arithmetic. It didn’t work out, so we have a decision. Do we split the story and take partial credit—hiding the issue OR do we just handle it congruently, move on, and strive to get better next time?

SideBar Story

I once coached an organization where each of their teams had about 25% of each sprints stories remain incomplete at the end of each sprint. It happened so often that they created a term for them—Continuation Stories.

It got even worse. Continuation Stories had a tendency to cascade across more than one Sprint. In fact, on average they spanned 3-4 sprints before they finally were completed and considered “Done”.

Because they “split” the work at the end of each sprint, their velocity appears sound. And because Continuation Stories, became the norm, they really didn’t talk about them much in retrospective.

However, their customers were paying attention and realized that 25% of each sprint was missing. Not only that, but undone work crept into subsequent sprints and continuously undermined the amount of work the team was delivering.

Point being—it was noticed and it wasn’t “good”.

Wrapping Up

I’ve wanted to discuss story splitting as a result of execution and delivery dynamics for quite some time. I think another discussion on a Rally forum was the initiator then as well.

It’s not that the tools are bad. But it is the fact that they encourage us to focus on the “arithmetic” rather than the behaviors we want to instill and inspire in our agile teams.

In this case, I don’t care about the interpretation of velocity or the reactions to turbulence. It happens. What I want the team to focus on is (1) hold firmly to their Definition of Done, (2) if something isn’t completed, determine what happened – exploring root cause(s) and then (3) do something about it to improve their abilities to plan and deliver on their future commitments.

Whether you “split” your stories or not, I hope this article caused you to pause and consider how you handle partially completed work within your sprints.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Micrognosis: A Pre-agile, Agile Story

I want to share a story from a Galaxy Far, Far Away.

It’s been on my mind quite a bit of late, as I tell it in some of my agile classes. However, I’m unsure whether the students believe me or they glean the significance of the story. I usually share it to illustrate a key point around software requirements. I usually get LOTS of pushback in my classes surrounding the “goodness and need” for fully documented requirements in software projects.

And as I unfold the agile approach to requirements (user story based, conversational, acceptance-driven, intentionally incomplete, and did I say collaborative?) the class starts turning ashen-faced in disbelief. Particularly attendees who are Business Analysts, Project Managers, and Testers struggle with the essence of agile requirements.

So that being said, I thought I’d try telling it here by writing it down.

From 1987 – 1996 I worked at a company called Micrognosis or “Micro” that was based out of Danbury, Connecticut. And no, it was not a medical or pharmaceutical company. The history of Micro was in the financial trading sector, in fact, mostly in the front office part of that business – providing complex trading stations for financial traders. And the company is no longer with us, but that’s another story.

If you’ve ever worked with financial traders as customers, I’d argue that they are some of the toughest customers—period! They were demanding to the point of obnoxiousness, and not just the New York based traders ;-). They had lots and lots of money to spend, but they expected to get the ‘world’ for their purchases and investments. They often operated 7×24 and expected their vendors to do the same. And the attitude and language; lets just say, it wouldn’t be well received in my current location in the South.

Engagements

Our typical engagement at Micrognosis was to sell our clients a “trading floor”. That would include all of the desktops, displays, video sources, digital sources, and cabling & networking infrastructure to distribute trading information to their individual traders. For example, I remember we sold JP Morgan a +800 seat-trading floor on 60 Wall St. in the early 90’s. It was one of the largest trading floors at the time and a real coup for us. I believe the price tag was a base of $40Mm which was, for Micro, more than we had made in the entire previous year.

And the way we structured our deals was as fixed scope, fixed date engagements. The clients would often schedule their traders to move and be ready to begin trading on our go-live dates. Moving the dates was physically not an option, as people were coming into work AND they were expecting to be able to make money for their firms. Rarely was there a fallback or contingency plan. Risk had to be anticipated and contingency planned as part of the overall execution plan.

And failure was literally not an option.

The Bottom Line

The way we structured all of our deals was with heavy contractual penalty clauses if we “failed to deliver”. And since most of our clients had oodles of money and attorneys, the penalty clauses were huge. If any one of them triggered, it would have destroyed our company. And no, I’m not exaggerating here. Because of the nature of our engagements and the industry, we had no choice but to compete in this:

  • Fixed Date;
  • Fixed Scope;
  • Fixed Performance;
  • Be able to make the same amount of money on go-live date universe.

And not simply compete, but win.

The Reality

But the reality was different. Yes, we signed off on these contracts. But here’s the interesting part of the story:

First, we never delivered on 100% of any contracts scope requirements
And second, we were never in violation of our contracts. Or put another way, our customers never once sued us.

So, here’s the question, how can that be?

Here we are dealing with some of the toughest, most demanding clients on planet Earth. And we’ve signed an ironclad performance contract. And we are clearly in violation of the “letter of the law” of that contract.

But nothing happens. And even stranger, our customers were “happy” with every one of our deliveries. In other words—they made their money on their go-live dates.

So, How did we do it?

In hindsight, I think we were incredibly agile. Amongst a relatively wide variety of tactics, here are three key things we focused on:

  1. We never simply followed the contract or the defined scope. Instead we would continuously interact with our clients and try to understand their needs for their go-live date. These were always different from what we had captured in the contracts. And we relentlessly pursued this understanding from contract signature through go-live.

    We never rested with the false belief that we understood exactly what they wanted. And these conversations were not solely done via email and document exchange. We put a real premium on face-to-face conversations. And sitting with our clients as they traded—so we understood exactly what each of them needed to be successful.

    We collaborated face-to-face with our customers in real-time to clearly understand their specific needs to get their jobs done. And if the needs were different from the documents, we adjusted to their actual needs.

  2. We had a strong team of developers and testers who fundamentally understood the financial trading market. Heck, some of our developers were part-time traders. And these teams had been doing this for quite awhile. We had very solid understanding of our business and technical domains. We maintained low attrition and high energy with a servant leadership model and one where the teams were largely self-directed.

    We paired, worked in small groups, continuously iterated, and interacted with our clients and DevOps staging environments. We focused on high quality solutions that were resilient. Even to this day, I hear from former Micrognosis colleagues who found it to be the pinnacle of their technical teaming experience.

    We hired great people, we valued and retained them, and we empowered them to do what it took to deliver on the goals of our customers.

  3. We relentlessly tested. I can’t say it any other way than that. In fact, we would setup our client networks, not a simulation but their exact infrastructure, in our Danbury facilities. We would test iteratively for functional and non-functional performance. We would setup individual trader positions and even test the data sets and applications that each would receive. By the time we shipped the systems to the client site, they were fully qualified. Dare I say it, the Engineering and DevOps teams worked side-by-side to deliver well-engineered systems that simply…worked.

    Were we perfect? No. But we collaborated fully across all teams and functional groups that were involved in delivering working systems to our clients. Think concept (client contract) to delivery (field operations) here as our value stream.

    We relentlessly simulated our customer environments (systems, applications, data, performance requirements, etc.) as we iteratively built customized systems for them.

Sometimes people challenge me and imply that this isn’t novel nor does it sound very hard. I respectfully disagree with them. Micrognosis had to work very hard to be successful and our agile behaviors were key to our successes. It’s just too bad that we didn’t have a sexy methodology to tie to our efforts at the time.

Wrapping up

I remember my time at Micro quite fondly. We had a great group of employees who worked their “tails off” to delight our clients. But beyond that, we became intimate with the market and with our clients needs. That needed to be a relentless pursuit and we were incredibly good at it.

And once we found out what they needed, truly needed to solve their challenges, we were focused in our design of high-quality systems that we assured would exceed their expectations and needs. Every feature we delivered was designed, implemented and testing with the clients’ environment and direct needs in mind.

We didn’t implement something because a document said to. Instead, we asked, collaborated, iterated, and sought to understand what was truly needed.

I’m incredibly proud to have played a part in it for as long as I did. Finally, to all remaining Micronaughts wherever you might be, I wish you peace and slightly “nicer clients”.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Postscript
Micrognosis was initially independent. Then acquired by CDC Corporation. CDC sold the company to CSK, a Japanese firm. They renamed it to CSK Software.
Along the way, the company acquired many small companies in this space, including: Quay Financial Software out of Dublin and FD Consulting out of Staten Island.
Micrognosis ‘dissolved’ around 1998-2000 as a viable entity.

3 Amigos in Agile Teams

I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:

  1. Developer(s);
  2. Tester(s);
  3. and the Business Analyst or the Product Owner.

It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

In my classes, I literally explain this as an “extension” of agile team pairing—in that I’d prefer the pairs to be converted to “Triads” around each story. Believe it or not, Ken Pugh leveraged the term Triad in his book on the same “ATDD-ish” driven topic (see the references).

3 Amigos Meeting

Recently I’ve heard of teams scheduling 3 Amigo style meetings as a part of grooming their backlogs. The idea is to create a checkbox for each user story where it has to be “3 amigo-ized” before it’s deemed ready for sprint execution.

I explored this notion of readiness in a previous blog post.

While I like this idea, and I certainly think making it a part of “Ready” is quite creative, I’m slightly troubled by the practice. I personally think the 3 Amigo’s analogy is less of a meeting and more of a collaborative mind-set.

So when do the “Amigos” meet?

Certainly they meet as part of Product Backlog development and grooming. I think that’s a given. But, I’d like to say continuously as well, for example:

  • Collaborating in the Sprint Planning meeting around how the stories fit into the Sprint and what the Sprint Review will look like from a cohesion perspective.
  • Chatting when each story is “first picked up” within the Sprint to ensure the team understands the nuance of the story and how to effectively design and test it.
  • During story development, the Amigos periodically check in together to ensure the story is on-track. Usually demo’s of partially completed code drive the discussions;
  • Once the story is complete, the Amigo’s gather around it and execute it. Going over acceptance criteria and other attributes, until the Product Owner is satisfied and “signs off on” the story;
  • But their role isn’t quite over. The Amigo’s play a strong part in demonstrating the story in the Review, gathering feedback, and digesting whether the story is truly complete. If so…they move onto the next, and the next, and…

What it’s not…

At the risk of “picking on” Jon Kruger (see references), I want to use part of his description to make a point:

Outcomes

The primary outcome of the three amigos are acceptance tests written in Given/When/Then format. Actually writing these out can take a little time, so we don’t do that with everyone sitting in a room. Typically a developer or a tester will work on it outside of the meeting, and once they have the scenarios all written out, then we do a quick review with everyone else that was involved in the original three amigos meeting to make sure that we all agree with what was produced.

I beg to differ with Jon. His description is much more focused on the 3 Amigo’s as:

  • Implying a meeting with specific, process-driven activity;
  • Implying exhaustive scenarios, written in advance;
  • Implying a prescriptive format of Given-When-Then;
  • Implying sign-off on acceptance tests, prior to the story entering the sprint.

What he, and many others seem to miss is the mind-set part of the Amigo’s that is continuously happening around the team. Please don’t loose that focus in your thinking.

Wrapping up

George, Ken and many others have struck on the collaborative power of these three roles within agile teams and their work. Don’t get caught up on it implying a meeting or any other ceremony, although those things may be outcomes of it.

Instead, consider it a role-based reminder of who needs to collaborate around the work that agile teams are producing continuously. Also think of it as a pairing surrounding sprint activity (the work) rather than a meeting-based activity (talking about the work). I think that was always the primary intent.

But please, do talk about “Amigos collaboration” early and often within your teams. The real point is that you’ll build better, more valuable, and more relevant software as a result. Now isn’t that something worth hollering about?

Stay agile my friends,
Bob.

References

Getting the “User” out of User Stories

In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirement within agile teams.

Most seem to be a using the standard phrasing construct for his or her stories:

As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?

Because the “User” clause is so simple, I see many teams who fill out their user stories in a by-rote fashion. They’ll literally have hundreds and hundreds of user stories, features, themes, and epics and all of them have “User” as the user.

I think they’re missing a wonderful opportunity to make their user stories, well, more usable and more customer-centric. That’s where I want to go in this article.

The “User”

I consider the user clause in the user story to be a “mini persona”. I’m not a UX expert, but to me a user persona is a description of a user, or better yet, one of your customers. It gives sufficient background on them, their experience level, their perspective, and their problem space, that it helps someone to “visualize” the specific customer.

From a software perspective it helps with all aspects of software delivery. Most importantly it helps us in creating the customers experience in I using our products.

A Story

In 2009 I joined a company that was implementing Scrum to deliver an email marketing, SaaS product. The company’s name was iContact and if you’ve followed my writing, you’ve probably heard about them before. When I first joined, I had a fast paced challenge to ramp up quickly.

Sometime in my first few days, I overheard a couple of Scrum team members talking. As I got closer, they seemed to be talking about me – Bob.

One of them said – It’s not clear to me whether Bob would approve of the design of this feature. It assumes an awful lot of application knowledge when setting up the report template.

Another replied – I think Bob is a bit smarter than you’re giving him credit for. Sure, he’s managing a small business and is overloaded with everything that is involved in that. But he’s a 40-something, college grad, with solid technology and computer skills. Point is – I think he’ll be able to quickly “figure it out”.

Still another replied – I disagree. Bob is not that smart and I believe he’s more technology phobic than literate. Remember, he had to call Geek Squad to install and setup his computer system. He’s fairly clueless, so we’ll need to make it more intuitive.

At this point, I wanted to interrupt their conversation and set the record straight that (a) I certainly wasn’t clueless, (b) I wasn’t technology phobic, and (c) that I didn’t appreciate them talking about me in the hallways.

But then it dawned on me that they weren’t talking about me. Whew! They were talking about the customer Bob, or actually our persona of a customer which we named Bob. I was incredibly glad that I didn’t embarrass myself 

Persona’s

My story actually helps define a great deal of the intent behind develop customer persona’s within your design teams and then sharing it across your agile teams. It helps the team to start to understand the customer. By giving them just enough information to put themselves “into” the customers’ perspective.

In this case, one of our personas was named Bob. Bob had a particular profile with respect to his background and needs for the Small-Medium sized Business eMail marketing tool we had built at iContact.

What was even more exciting was the fact that the team was talking about Bob as if he was real. And they were actively considering him, his unique perspective, and his needs for the system as they built out new features. That’s exactly the point of developing the personas in the first place.

There were Five

In our case Bob wasn’t alone. We had developed a set of five personas to represent key aspects of our customer base. For example, one of the personas was very well educated and the other had a high school diploma. One of the personas was relatively comfortable with computers and technology and one of them was not—being simply a storekeeper trying to “dip their toe” into email marketing.

We hung printouts of the personas all over the place to remind everyone of “who” are customers were and “who” were building our products for. That’s another reason that conversation was going on, we had had socialized our personas so well that they became almost real people.

Not just for design

And the personas didn’t simply stop at design. For example, our testers found them incredibly useful in determining what and how to test. We were constantly using risk-based testing techniques and prioritizing our testing. When decisions on what, how and when to test were being mad, we often examined the personas—knowing that we had to keep our customers “whole” as a part of our testing efforts.

Here’s a wonderful article that speaks to this aspect of persona development.

Wrapping up

So instead of stories that all looked like this:

As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?

We had stories that looked like this:

I’m Bob
I want – Feature or Functionality
So that – I can achieve very specific goals for my business

As well as stories for Jane, Todd, Beatrice, and Sam.

You might think that it doesn’t make a difference. But I found that “putting on the hat of the customer” makes a great deal of difference in how we:

  • Envisioned
  • Prioritized
  • Designed
  • Built
  • Tested
  • and Deployed

Our products. In the end, it’s ALL about the customer. And while we say that, personas make it much easier to envision who they really are.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References