One way to bridge the gap from raw requirements to user stories

I’ve been on two Agile projects now where the following has worked.  Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?

brainstorming-sessions

Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming.  They come out with a bunch of requirements.  They leave.  The dev team now has to figure out how to take this long list and turn it into develop-able requirements.  We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc.   But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project.  So here’s one way I’ve seen that works:

Assuming you’ve got that list of requirements I mentioned earlier:

Move requirements into Features

Raw

Analyze the requirements as follows:

  1. True Need Analysis – Figure out what the real requirement is behind the ask.  This is usually the domain of the BA. What is the user really asking for?  For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
  2. De-Duping and Current State-ing – Figure out what requirements are really mimics of each other.  For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible.   Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need.  So give the requirements a current state pass as well.
  3. Grouping and Aggregating – How do requirements  logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product?  Spend some time grouping those requirements together and give that feature a name.
  4. Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

Prep the Features in a Spike

Grouped

To fully Prep requirements, create a spike.

What is fully Prepped?  It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.

Handover the feature to the development team 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.
Cake
How are you handling this move from raw requirements into epics and stories? 

Prepping our Human Project Manager Selves for Crisis

A while back I wrote about the Project Management Institute’s 2011 Journal Paper of the Year by Manfred Saynisch.

“Here’s the deal – what Saynisch et. al. are proposing is a fundamental shift if the way we think about project management. We are moving from Project Management First Order to Project Management Second Order. And it’s all about the shifting collective beliefs…. Project Management theories and processes should start incorporating these ideas:

  • INSTABILITY IS TO BE EXPECTED
  • CRISIS IS AN EXPECTED OUTCOME
  • RAPID EVOLUTIONARY JUMPS PROVIDE A CHANCE TO EVOLVE TO A NEW LEVEL, EMPLOYING THE PRINCIPLE OF CHANCE”

As PMs we do expect a bit of progressive momentum on our projects, regardless of the method we choose. If we are in an iterative project, we expect progression to the plan. On agile projects we expect a certain rhythm; standups by day, planning, showcases and retros every few weeks.

 

But what happens if we accept Saynisch’s idea that we should accept that instability, crisis and rapid evolutionary jumps will occur, just when we least expect them?

Here’s the issue: we have the techniques and tools to plan for crisis (though I would argue most places don’t use them), but we don’t really talk about what our approach will be as Project Managers when control is seemingly lost. How do we, as people, make it through? How do we prepare our thinking for crisis? What expectations do we have about what we will or will not do during those times?

A Short Minor Crisis Story

I have one story, a positive one, about managing through minor crisis. As a program manager at a small company, I had been working hard to raise the level of project management maturity. With over 30 projects, we hadn’t connected projects to strategic programmatic goals and we had not prioritized the projects. People were going slightly nuts.

I (obviously) wanted to get a handle on this. Over time, I developed the relationships to have the senior leadership trust me enough to begin to work on these issues. After a number of months I was able to get all the execs in a room for a portfolio planning exercise.  And the goal was simply, place the projects into strategically aligned portfolios.

Within minutes it became apparent that my plan was going awry. The cool card sorting thing I envisioned was confusing people. And the discussions were moving away from the topics I wanted. And I thought ‘ dammit, I’m about to lose a golden opportunity’. The execs started questioning why there were there. Schmuckers!

But..I had done my research. And I knew where the problems lie and I started to honestly communicate. I admitted immediately that the method I had envisioned to solve the problems had gone a little nutso, but reiterated that we could still solve the problems we faced. Then there was discussion amongst them, and I sat back and let it unfold. Which was hard. I didn’t know where it was going. But the problems we faced had been laid out before us, and we all knew we had to solve them. And then, like instant magic, they decided, en masse, that instead of portfolio planning, they were going to prioritize projects.

And I was like ‘Booyah!!’. That was better than I could even have hoped.  My original plan got thrown out the window (thank God), and during the turbulence between the old plan and the new, the things that helped me keep up forward momentum were:

  • the relationships of trust I had with the team (they’re thinking “Michiko’s not an idiot, so I think we must be here for some good reason”),
  • the knowledge I had (I’m saying “Hey folks, we have some serious issues to solve here; here’s example 1, and here’s example 2”), and
  • it was ok to abandon the method to move forward (“well, looks like the card sorting exercise is a bust, but what can we do to solve our problem”).

And the outcome was fabulous.

It could have gone something like this: I keep trying insanely to stick to a method that obviously was not working, I shut down. I say something like ‘ok, we’ll pick up at some other time.’ They then lose faith in me, I lose some cred. We stop moving forward.

Preparing our Human Project Manager Selves

Saynisch’s model says that we should expect crisis, and out of crisis we will experience evolutionary jumps. I think the implication of that model is that we need to plan and prepare our personal response to crisis.

In other words, what are we thinking when the you-know-what hits the fan?  How do we manage ourselves well, so that we have the right expectations and subsequently help to manage others well?  What do we hold onto and what do we let go to make it through?

What I’m suggesting is that shifting our paradigm to expect crisis also involves shifting our approach to project management during these times of crisis. I thought I would share with you some of my own learning from crisis periods, and how I’ve adjusted my approach to fit those crazy times.

So here are three things that I think happen during crisis and three changes in thinking that I think may help you prepare and manage through crisis.

In crisis, trust relationships trump authority

Trusted enough to run a movement from jail. Master of relationships.

Crisis represents the breakdown in normalcy. And during crisis the normal reporting relationships and hierarchies will not be as important as who people actually trust. In crisis, people will follow who they trust.

Implication: If you want to lead through crisis, develop relationships of trust.

Build your relationships. Work to appreciate people and what they do. If you have beef with people, try to work it out. Make sure you know the names of everyone on the project and understand what they do and how. Take time to talk to people about life in general. Revisit your own methods, see where you can adjust if you have an area that needs work. Read a self-improvement book. Read books about team building.

This Guy (the one standing up)! Knows everything. And no one follows him UNTIL the crisis.

In crisis, knowledge trumps authority

Similarly, people will most likely follow those who know how to get out the crisis, not the stated authority figure.

Implication: If you want to lead through crisis, keep learning; fill yourself up with knowledge. The more you know, the more you’ll be able to quickly connect the dots to develop a plan for getting out of the crisis.

During times of normalcy, become knowledgeable about everything related to your project; how the enterprise works, what systems do what, how communications occur. Most importantly know the intimate details of your project. Read the requirements, read the test scripts, understand the business benefits and know why the enterprise needs to achieve them.

In crisis, forward momentum is more important than method

Turns the method on and off as needed.

During crisis, Its more important that group feels that they are somehow making progress rather than that they are following the norms and rules of methodology.

Implication: Be willing to abandon the method, in favor of forward momentum. And then communicate like crazy, all the time. Because method is really about communication. And you’ll have to pick up that slack.

Be hard on yourself about communication. Make sure everyone knows as much as they can. Walk around. Tell people. Email. Post it on Yammer. Use every form of communication you can to tell people what’s going on.

Avoiding the Shutdown

Here’s what some people do in chaos: Shut down. Stop communicating.

Why? Because they don’t have the knowledge, they don’t have the relationships and they realize that without both they won’t be able to do the communication necessary to keep forward momentum going. And they know that as soon as they start speaking people will realize it. And in extremely chaotic situations, people will stop following them and follow the person who does have the relationships and the knowledge.

Let’s prep ourselves to avoid the shutdown.

Talk Back

So these are just a few ideas to start the shift in thinking. What do you think? What crisis experiences have you had to manage through and what did you learn?

One Small Thing

Today I’m inspired by Richard Branson, founder of Virgin Airways.

In providing his best tips for starting a successful business his number 2 is,  “Keep it Simple”. He says

“You have to do something radically different to stand out in business. But nobody ever said different has to be complex. There are thousands of simple business solutions to problems out there, just waiting to be solved by the next big thing in business. Maintain a focus upon innovation, but don’t try to reinvent the wheel. A simple change for the better is far more effective than five complicated changes for the worse.”

A simple change for the better is far more effective than five complicated changes for the worse. – Richard Branson

Have you ever been on a project where things changed massively all at once?   Sometimes the change is necessary but there’s no denying it wrecks havoc on relationships.    I’ve been that PM in the past, the one who wanted it all to go by the book; the perfect project plan, absolutely correct adherence to the SDLC (whichever method we chose) .. and I would push really hard, early on.  And wind up being the one who bought in ‘five complicated changes’ that inevitably made things worse.

And it wasn’t methodologically worse; it was relationship worse.   The changes were so sudden, they pushed people immediately into taking sides.  People never got to really know me as a person, I just became that PM, the one pushing everyone’s buttons the wrong way.  I hadn’t learned this truism that really…

…One simple change for the better would have been far better than the perfect methodology (and the 5 changes that came with it).

Now, I’m a little bit more relaxed.  I see things every day that I wish I could change, or hear things that make the SDLC-lover inside me want to run for the hills.  But…its one thing at a time.  Crawl.Walk.Run.  I’m focusing my energy first, on appreciating what people are doing, rather than trying to analyze them against a methodology checklist.  Second, I’m looking for that simple change that will make things better for everyone.

Here’s one idea from the most recent PM Network  A PMO in Kentucky doesn’t force low probability risks into the risk management process.  “ ‘We make note of it and discuss it informally.’ Says Janice Weaver, associate vice president of the EPMO at Norton Healthcare. ‘But we don’t spend hours on tasks that don’t add value to our process.’ “

What’s one small thing could you do on your project that would make things better?

Here’s two guys who’ve mastered simple play Simple Gifts..wouldn’t it be awesome to feel like this at work!

 

Help I’ve Lost My Measurable Benefits (and I Can’t Get Up)

I had to get myself unstuck recently and I thought I’d share with you what I’ve learned.

Help! I’ve lost my measurable benefits (and I can’t get up)

My problem is that pre-project measurement and analysis time is a virtual luxury for small and medium sized firms given the highly competitive environment we are in.  And so many projects begin with more intangible, unmeasurable goals than tangible measurable goals.  Which means that while success can be obviously felt, seen, touched;  it can be hard to prove.

It would be nice to get, for example,  ‘approximate processing time for purchase order task completion’ baseline measurements before starting a project.  But  it’s kind of hard to do when the users sound a little like this: “OMG IF I HAVE TO FREEKIN PUSH ANOTHER FREEKIN BUTTON TO FIX THIS DAGGONE PURCHASE ORDER I’M GOING TO THROW THIS COMPUTER OUT THE WINDOW”

Upon which, the system/powers that be say – OK, let’s move forward with a new system.

And then the PM is now writing up a project charter for the project to get a new system and runs into ‘what are the benefits/capabilities’ to be gained in this system to which they say something like ‘improved productivity’.

But there’s no baseline measure, and so this basic benefit, something really super important to the success of the project, usually remains intangible; something that is felt rather than measured, perceived rather than calculated.

A Program Manager’s Greatest Fear

That’s where I’m stuck. Because as the Program Manager I’m telling the PMs, ‘the project will be evaluated by the realized benefits’, and the PMs are saying ‘but the benefit is unmeasurable.’ (which in actuality really means, we don’t have time to do an analysis phase on this thing, we just have to fix the problem).

As an aside, there is growing support for methods used in identifying and tracking benefits. Collectively this body of work is operating under the coinage ‘benefits realization’. I’m incorporating benefits realization into our process. See Thrope ‘The Information Paradox – Realizing the Business Benefits of Information Technology’. And see the Benefits Management process in the most recent Practice Standard for Program Management.

So the question is: Is an unmeasurable/intangible benefit ok to use as project evaluative criteria?

I think the answer is Yes and No.

No in that while we may not be starting with a baseline to compare to for measurable benefits, that doesn’t mean we can’t still define a goal and measure that goal. I think we have to have some type of measurement of benefit or intended outcome for every project.

Yes in that we should strive to be very clear about the intangibles. Even if we can’t measure them, we need to acknowledge them, list them out, clearly state them. The intangibles provide the nuances that can make or break success. For example, I want a car that gets 35 MPG (tangible), but it also has to be cool (intangible).

So the challenge then is how to help project managers identify measurable (tangible) benefits and unmeasurable (intangible) benefits such that even if we don’t have a measurement baseline to jump from, we can at least find some definable goals to reach for, with intangible descriptions to shore up the tangibles.

Here are some helpful things I’ve found to do so.

Clarity on intangible versus tangible

In their book Enterprise Programme Management, Williams and Parr assist with this definition:

“Benefits fall into three categories:

direct financial benefits: those that can be quantified and valued (tangible)
direct non-financial benefits: those that can be quantified, but are difficult or impossible to value (tangible)
indirect benefits: those that can be identified but cannot easily be quantified (intangible).”

Some Tangible Benefits Examples:

  • Cost Avoidance
  • New Income
  • Additional Income
  • Reduced Working Capital

Some Intangible Benefit Examples

  • Strategic Alignment
  • Competitive advantage
  • Competitive response
  • Improved customer service
  • Kick Butt Communications (from my company ;) )

For tangibles, use precise measurement terms

Thorpe suggests using his MEDIC acronym to derive precise language to describe benefits. Instead of ‘effective’ or ‘better’ use terms like ‘maintain’ or ‘increase’.

  • M: Maintain – e.g. a level of service maintained
  • E: Eliminate – e.g.a function eliminated
  • D: Decrease – e.g. turnarond time decreased
  • I: Increase – e.g. revenue increased
  • C: Create – e.g. a certain capability created

From Information Systems Evaluation Management by Wim Van Grembergen

Finally, we can give easy benefits examples, perhaps in a ‘benefits list’ document.

Here are some examples I’ve found in the field:

I can say that all the projects we’ve done in the past year have had efficiency, productivity, and regulatory expected outcomes, even though we may not have measured where we started from at the beginning. We are now seeing those outcomes come to fruition; as well as perhaps the one intangible that I like but that rarely gets written in a project charter; a happier work environment.

Fundamentally though, I think we still need clearer direction on how to identify benefits.  We’ve got good processes for managing benefits, but I would love to see more easily accessible guidance on benefits identification.