I love to do storyboards. This artefact really enables you to communicate the essence of what an application, process, or policy will have on the business by just telling a story with archetypal users (aka personas) as the protagonists. But once you’ve done this is that all there is? What else can you do, or should you do, with your storyboards.

I turn my storyboards into epic requirements on an A3 page and display the logic of the storyboard along with:

• The feature as detailed on the storycard
• The user-experience (UX) to show the basic flow of choices and actions
• The business process at a high-level — just enough for someone to understand what the business rules are
• The system components that support the UX and and business process
• The personas used, their requirements, and the business requirements

What I end up with is a discrete piece of the solution described in just enough terms so that everyone has a sense of how all the pieces of that solution go together. Some people like to call this approach ’skinny documentation’. I like to call it ‘zen documentation’ — simple, elegant, minimalist yet comprehensive and uncomplicated.

The template is available under a Creative Commons Licence from one of our other posts on ‘requirements on a page‘.

M

So I recently read: User Storied Applied

I would have to say that I do recommend it if you can get it for cheap.  It did have a large amount of good information, but it did have a whole lot of fluff also.

In the essence of keeping things simple:

Good:

• Examples of good user stories.
• Good process ideas about how to “troll” for stories.
• Actual real example of developing user stories for a product and estimation.

Bad:

• Lots of pages filled with the same exact information.
• 10 completely blank pages at the end of the book.

What I learned:

I was trying to put all the done criteria into the story making it more like a requirements document, this was bad.  Better to have a small story that is used as a reminder to have a conversation later with the customer.  Where does the “done criteria” go then?  On the back of the card, or eventually into the story, but after talking with the customer, not during planning or before planning.

I have three questions I expect to be answered by the customer for me to be able to complete a story:

1. What is the system currently doing that you want changed?  (If this story’s feature is completely missing, that is a valid answer)
2. What do you want the system to do after the change is made?
3. How can you prove right now that it is not already done?

After reading this book, I have learned that these questions can be deferred after planning, they don’t have to originally be in the story, but someone still needs to be able to answer them.

Storyboards are a great way to describe a user’s journey, their thoughts, feelings, attitudes, capabilities, behaviours and expectations, throughout a single scenario. They’re light-weight, easy to do, and as a visual tool can be used in workshops or just by a couple of members of the team. They also work perflectly on agile projects because they’re visual and, therefore, an instant placeholder for a conversation.

Here’s my tips for doing your own storyboards:

1. Do your personas first. This way you’ll know, even at a basic level, who the people in your stories will be, how they think about their work and their behavioural attitudes.

2. Put the persona into the scenario: From the persona’s perspective describe their thoughts and actions as they try to undertake the actions required of the scenario. This is where the user stories written on your agile story cards meet your personas on agile projects.

3. Stick to a single scenario: You’ll be tempted to start to include a whole range of other things in your storyboard. Just keeping it simple will help. The only rule is that the storyboard must be logical and tell a user’s story from beginning to end.

4. Stick figures are ok to! Many people shy away from storyboards because they think they can’t draw. But if you can draw speech bubbles, thought clouds, and a stick figure then you can draw storyboards. If you draw some hair on the stick figure then you can differentiate between Steve and John — which is very useful when one user in the storyboard is, for example, sending a message to another because then you need include both of them in the story.

5. Include thoughts and feelings: It’s easy just to describe the logical sequence of events. The story becomes more personal, though, and thereby more real, if you include thought clouds and speech bubbles. This will ultimately mean people will be able to identify with the story and thereby make your storyboards more effective.

6. Post-its and pens: I always use storyboards because I can do it in a moment’s notice with a Sharpie and post-it notes. This makes it very easy to swap post-its around, draw new ones, until I get all the logic right.

I then take a photo of the storyboard sequence (everyone has a camera on their phone these days) as a baseline and take the post-its into a workshop where I validate my logic by comparing it to the way users’ sequence the elements.

If necesary, I’ll then take the storyboard and convert it into a workflow diagram in Visio as a communication of the user-to-system interactions that helps to clarify use cases for the BAs and developers … but that’s a blog post for another day.

M

1. Identify your users’ stories

As I studied users’ thoughts, I found patterns in what my project was really designed to do, above and beyond what the project brief said. I listened to what my mind was drawn to listen to. These were the users’ stories — what was most important in their working lives.

There are no right or wrong answers in listening. Be honest with your users that you’re there to add value to the way they work and their stories – needs, expectations, attitudes and capabilities – will become clear.

2. Embrace your users’ needs

Once I am aware of users’ needs, it is far easier to design according to them. When faced with a decision, I can compare it to their values by documentation as personas, and see it will bring me closer to a solution that is fit for them, rather than what is easiest for the project team to produce.

3. Accept expanding feature sets

A ZenAgile mind does not struggle. It accepts users’ needs as they truly are. A rock is a rock. It will remain that way no matter how much you worry, wish, or pressure it into changing. Worrying about requirements and ever expanding user wants are the same way. I accept requirements for what they are, do not waste time or energy fretting over it, and group them into feature sets for delivery in such a way that, as a whole, they add value to users’ work.

4. Energise for change

A ZenAgile mind can give you extra energy for change as you are not wasting energy fighting against the inevitable. As above, there is a large rock in your way. You have three options:

• run into the rock repeatedly
• agonize about the rock being in the way, or
• find a way around the rock.

Before ZenAgile, I chose the first two options. With ZenAgile, I now accept the rock for what it is: an obstacle. I accept that you cannot go through it. I do not panic, and waste time and energy worrying about the obstacle. Instead I make my own path around the obstacle, either over the rock, around the rock, or under the rock.

This is Seijaku (静寂) — the energised calm.

5. Enhance knowledge of yourself

As I practice ZenAgile, I spend a fair amount of time in conversation with others and thereby understanding myself and how I come to terms with change: change in the project context, changes in requirements, and changes that need to occur to the solution.

In time, I’ve learned to quiet my mind. I’ve listened to the same fears for projects repeating themselves which inspired me to change what was causing those fears. I’ve realised, for example, that lack of a user-centred approach was a large source of anxiety, and so it was time for a change. Without time to think and meditate on the conversations in a project, we tend to ignore what our mind is telling us, and remain locked into our old patterns of doing things.

6. Gain confidence in the agile way

As you reflect on your inner self, you become conscious of who you really are, your role, and the skills you bring to aspects of the agile project. You learn what makes you happy, what is beneficial to your project, and where you fit into the multidisciplinary team. You bypass the fears and anxieties of your mind, what role you play — Business Analyst, Project Manager, Information Architecture, User Experience Designer, Change Manager — and focus on doing what needs to be done. Boldly and passionately complete the iteration. The opinions of traditional organisations like PMI, IIBA, ABAA, etc, do not matter, because you know you are doing what is right.

7. Appreciate the iterative project lifecycle

I accept the project as it truly is – evolutionary in nature, rather than revolutionary. You will always uncover new aspects of users’ needs. You will always uncover the unknown as you proceed boldly through the project. Some will be surprises like a starry evening, a stroll by the river, or a night of solitude. Each will have their own unique characteristics to be appreciated. Mundane user needs also hold their own charm. Observing the quiet details of the project lends value to the less appealing aspects, and brings peace and joy in commonplace tasks.

8. Increase consideration for others

Each person on the project is interconnected. We are all searching for the solution, requirements, and a meaningful project to work on. It is much harder to be angry at the user who argues with you about scope when you realise they are on the same path, just at a different point in their journey.

9. Simplify your project and your documentation

Conversation not documentation helps you differentiate between needs and wants. To document things completely today is to suggest that it will fix users and their workplace in time until the project has been completed. By focussing, instead, on a minimalist, simple project solution delivered in a short period of time, with just enough documentation to describe the decisions made, you are able to deliver value to people now and then build upon that solution to meet their future needs.

This is Kanso (簡素) — simplicity and elimination of clutter from the project

10. Cultivate a giving spirit by mentoring others in the team

When you are doing your role in the best way you can, your heart fills with joy. You are doing what you were put on this earth to do, and doing it to the best of your ability. Your life is simple, you are living your values, and you have a clear mind. You can then give to others, mentoring and teaching with a loving spirit, to help them along their path.

This is the True Way of ZenAgile

M

We have received this Restaurant City real life story from xnadchrist – thank you xnadchrist for sharing your story with us. It just goes to show, there is plenty of things to do in Restaurant City and the game is ever evolving. We at Playfish are always working to improve the game experience for all our players. You defintely have not seen the best of Restaurant City yet!

Over various projects I have applied a set of Agile practices from eXtreme Programming and Scrum. Adding personal insights to specifically handle fixed price (-negotiable scope) projects resulted in my My.Fragility framework.

The framework includes a Product Backlog Estimation model, for which the main estimation process steps were highlighted as part of my Definition Of Agile Planning. Furthermore does the model at least imply an understanding of my definition of a User Story:

A User Story describes a feature from an end-user perspective. It is independent of software layers or parts of the project

A User Story can be explained as an essential Use Case

A User Story should be INVEST to be ready for development

• Independent: User Stories have as little interdependence as possible. Resolve it by putting related Stories in the same Sprint
• Negotiable: a User Story is an invitation to discuss implementation. The best design and code result from communication!
• Valuable: a User Story represents effective business value for an end-user
• Estimatable: the size and knowledge on a User Story is sufficient to reliably estimate the Story
• Small: a User Story is small enough to be estimated, developed and tested. It is comfortably realizable in one Sprint
• Testable: a User Story has a clear result that can be tested

Recently I’ve started to think about the concept of time-boxing for user stories.  In Scrum, most things are, can, or should be time-boxed: sprints, releases, planning sessions.  Providing a time  constraint has demonstrated value: it limits the scope of effort, it can curb expensive and unnecessary perfectionist tendencies, it eliminates waste, and it forces prioritization.

One thing that Scrum doesn’t promote is time-boxing of user stories.  We know that user stories are designed to place-holders for future conversations — in other words they aren’t complete and detailed requirements.  We also know that user stories are supposed to be estimated, and that estimates aren’t commitments (well, we should know that). So why does Scrum provide for time restrictions at a higher level, but not at the user story or task level?  I think I answered my own question: the level detail a user story would have to contain wouldn’t support an agile approach to development, and it would mean estimates aren’t estimates but instead are commitments, which we’ve learned is unrealistic in software development.  But I think there’s room to maneuver.

Specifically, in user stories which are complex or involve high technical risk, or in other words user stories that have a good chance of taking way longer than we thought, it can make sense to time box the story, or even the tasks within the story.  I’ve recently asked my team to try this — specifically as a response to ‘technical’ stories which have spun out of control.

Some ideas I’ve floated on how to approach this:

1. Pick a level of effort to commit to on a story; this should be done in consultation with Product Owner (PO) and ScrumMaster (SM).
2. Breakdown the time you need to spend on each task; if this is way beyond the original estimate of the story, have a conversation with the SM and PO.
3. Consider using the Pomodoro Technique to track your time (e.g. if you have given yourself two hours to work on a task, that represents four pomodoro sessions). This will make it easier to not let time get away on you.
4. Just as we prioritize stories in a sprint, prioritize the tasks and acceptance criteria in the story (with either the PO, SM, or architect if it’s a technical story).

Smells:

1. If your acceptance criteria is unclear, this is an indication that a conversation is needed. You should never undertake a story with unclear acceptance criteria — but this is especially true for time-boxed stories.
2. Track your actual effort against tasks and the story and raise the alarm if it looks like the story is out of control.

The final word on this is to use it with caution.  We usually cover around 15 stories in a sprint.  Time-boxing more than one or two is probably an indication that there are bigger problems.

I have to tell you, I’m on quite a Bluebeam high. Last week I had a fantastic time meeting with Bluebeam users and attendees at Greenbuild. And this week, I returned to the office to see all sorts of wonderful user feedback forwarded to me by my coworkers in Account Services and Tech Support. Here are some of my favorites:

“If I were to pinpoint one feature in Bluebeam that I find the most useful, it would be the Tool Chest. It allows quick and easy customization of editing that is not available in Acrobat.”
-Kubo

“I have to say that Bluebeam PDF Revu is easily the best PDF software I have ever used from both an interface and stability point of view (as contrasted to Adobe, FoxIt, and PDF Annotator, all of which I have used extensively).”
-David

“I love you guys!!! With out a doubt the best experience I have ever had with a software company, and I haven’t even purchased yet! Placing my order tomorrow, and telling everyone I come in contact with that if they work with PDFs, Bluebeam is King.”
-Frank

Thanks for all the kind words everyone, and remember you can always send your comments (positive or not) to me. And remember to keep on PDFin’!

-Karen

Agile ways are great. They are an enormous improvement to the old ways. However, that doesn’t make them “complete” or infallible. We should always be striving for better ways of working. One thing that has always bothered me is the “Magical User Story”.

You see, most descriptions of agile methods assume the customer knows what she’s doing and that she can, with some help from the “tech guys” maybe, create a prioritised list of her needs. Popular methods like XP and Scrum have very little to say about how the user stories are born. They’re just there.

This is nonsense, of course. User stories don’t magically appear out of thin air and dive into the product backlog, giggling with anticipation.

But wait a minute, I can hear some of you say, we have a role for that. True. There is this role in charge of the story thingies called the Customer or Product Owner. But does having a role really guarantee the effect we’re after? “- Right, Sir! You’re in charge. That’s settled then. Jolly good, there it is.” No. It doesn’t work that way. Just making someone responsible doesn’t mean we’ve got it covered.

The responsibilities and methods of a Customer/Product owner are described in a rather shallow way in agile methods, because the people who designed XP and Scrum et al were developers. They didn’t know exactly how that work could be performed in a professional way.

I am not saying that Customers/Product owners are incompetent – I am saying that the work they face with is hard, really hard. Most people believe that the Customer/Product owner should be just one person. Then, apparently, we won’t get that conflict of interest that having several customers normally generates. (Yes, we will, only it’s shielded from the developers.) But what if the work is simply too difficult to handle for one person?

I think that the role of the Product owner as one person is naive in all but the trivial cases. This is partly for practical timing reasons, how could one person stretch all the way from having intimate contact with the market, over using political clout in the organisation to get things done, to helping define and validate examples of how the system should work with the developers? Sounds massive, right? It is. Maybe they have a black hole in their pocket, because I can’t see how one person could handle that without some kind of time-control device. But most of all it is because that task is simply too difficult and important for one person to handle.

What is that task? Well, the main task of the customer/PO is to guide the product development in maximising its return on investment. In other words, they must decide what should be built. They must know the value of things. Now it gets difficult, how can they know this?

If I were to ask myself, an agile advocate, this question, I would answer: Release early, get feedback, refine and repeat the process. But that’s only a partial answer. Do we really have to settle for having to deliver some crap before we can start improving it? I am certain we can do better than that.

To be sure, iterating towards a better solution will slowly result in a better product but progress will be slow. Why is this? Because there is nothing in agile methods that make us connect on a deep level with our market – get inside our users’ heads. There is nothing on how we should select our business goals and steer towards them. There is nothing about measuring how well we succeed.

Just iterating won’t be enough. We need more skills. We need many perspectives for this task to do a good job: business process knowledge, technology skills, marketing and sales experience, and domain expertise. But most of all, I believe we need to connect better with our users.

Users are surely our most underestimated resource. As it has been said before, there is only one other business that calls its customers “users”… I think this rather well reflects what we think of them. And yet, they are the ones who know how to do the work, with or without our systems and products. They are the people who demand service and buy our stuff. Maybe we should start talking to them?

This post was co-written on Google Wave with my colleague Scott C. Reynolds and is a follow up to our previous post about good specification practices.

User Stories and Text

User stories and other text documents are the bread and butter of defining work, and we use them like crazy. Our story practice has evolved over time, and we have come to a place where we feel that, when used appropriately, our stories are very effective. For a deeper look at the guidelines we use to construct stories, I recommend you go check out Cat’s post on the subject.  Go ahead. I’ll wait.

Okay, welcome back. Here’s the thing, stories and tasks are only part of the equation. Stories alone aren’t enough to define a system however, and trying to define everything in text is a fool’s task. (I’ve been that fool)

Pros: tell a story, capture detailed information

Cons: text is not good for everything

Using the Right Medium: Mockups

Mockups are a very useful tool when specifying details of how things should work. With stories, you really can’t add a lot of design and implementation details or the signal to noise ratio becomes too high and shit gets overlooked. A basic rule of thumb we employ on the team is "things that don’t get communicated well in text shouldn’t be forced into a text medium." Basically, if you’re going to try to describe the way something should look in a story, a) it’s probably not going to look the way you actually picture it b) that story is now noisy as crap and people are going to ignore more important parts. With a mockup, you don’t have to take forever to do a flashy, literal, perfect screenshot in Fireworks or anything; you can just drag and drop Balsamiq controls around and voila. Ya got an aesthetically pleasing mockup that humans go nuts over. In five minutes I can mock something up in front of a developer, explain how it works, and they are ready to go.

Another great thing about mockups is that they are extremely useful for getting user feedback on specs without distracting the user that "this is the final product, no more input." You can use a mockup to discuss workflow and layout without getting mired in fine-grained detail. The last time I was at the lab, I went back to my hotel room for a couple of hours and mocked up apps for 4 workspaces, brought them back to the supervisors, and was able to get plenty of good feedback and make edits right there in front of them. Gold.

Pros: Time-saver, gives the gist of what you want, keeps your stories clean while still conveying what you want, good to show to users.

Cons: Can fall into the trap of putting everything on a mockup just like you would put everything into a story and it’s inappropriate

Using the Right Medium: High Fidelity Design

How easy is it to develop from what basically amounts to a screenshot? You know exactly how everything should look, you can strip images out, you don’t really have to think about it.

Wait a minute. There’s a red flag.

You don’t have to think about it? That’s a paddlin’. A high fidelity screenshot, while beautiful, robust, and easy to work from, gives developers a signal that this screen is a specification set in stone. They see what it needs to look like, they build it like that. It’s just like BDUF; the high level of detail and granularity means that people won’t think about what they’re actually building, they’ll just duplicate what they are given.

Pros: Hotness, high level of detail, easy to work from

Cons: Removes developer thought, can take a long time to create such a design

Using the Right Medium: Conversation and Whiteboarding

While each of these mediums has plenty of merit and many benefits, conversation and whiteboarding are my favorite methods of specifying work. There is nothing like having the team (or pertinent members) together, talking through the workflow of a feature/app, mapping out how everything works, doodling out a rough idea of what things are going to look like and how things will come together. It is so damned valuable to have the working group together, talking through how things are going to work and getting their input. While business analysts and managers can come together to specify the general nature of how things need to work, having different members of the team around will help to eke out edge cases or problems that may not have been thought of in original discussion.

Conversation is obviously important by itself too; user stories are written to leave plenty of room for conversation. If you lose communication on your team and people just go off to code in the dark, a lot of the intent and original specification is lost.

Pros: Mapping workflow, multiple sources of input, easy to sketch out an idea/easy to change an idea, whiteboarding is fun as shit, conversation fully fleshes out ideas

Cons: Easy to get lost if not captured appropriately

While we’ve clearly chosen a favorite medium, you really can’t use just one. Each medium has a lot to offer depending on the scenario you are working with, and just like any other thing, you have to use what works naturally for the team in context with what you are doing.

This post was co-written on Google Wave with my colleague Scott C. Reynolds, who makes me insane every day.  It is part of his How We Do Things series.

Where We Came From

We began our large LIS project in late 2004, starting with about 6 full months of writing specifications and designing the database. We created reams of documentation for each application complete with use cases that we knew we wouldn’t even implement until after the first version was released (sidebar: some of those still haven’t been done). We defined more than 100 tables of heavily normalized database schema. Before one line of code was written, we had spent six months of project budget.

As development continued on the project we found ourselves diverging from the specifications that had been created. The documents became little more than a roadmap, with the bold headers on functional groups and the basic usage stories becoming the guidelines that we followed. Much of the detailed specification and database schema went out the window as the system took shape and people began to see and give feedback on what was being produced. Too much specification gave us a false sense of "doing it right" and led us down many wrong paths. Balancing rework with completing planned features became a costly chore.

By the time the project was complete, it was clear that much of that up-front work had been wasted time and money. Had we top-lined the major milestones of such a large project, detailed a small set of functionality, and started developing iteratively, the system would have taken form much sooner, allowing for a tighter feedback loop and much less overall waste.

How We Do It Now

Lessons learned, we set about improving how we do specification. Scott already talked a little about this in the posts on planning, so please review those if you haven’t seen them yet (here and here).

When planning a new project of any size, we take an iterative approach. We start at a very high level, and strive to understand the goals of the project. What need does it serve? Who will be using it? Are we competing with something else for market share? Is there a strategic timeline? What’s the corporate vision here? What are the bullet points? We will fill in details later. We only want broad targets to guide us further.

When we get closer to development, we start to identify smaller chunks of functionality within each of those broad areas. This is still pretty high level, but done by business analysts and management on the IT team. We start to identify MMFs (minimal marketable features) and group them up in order of importance to help determine next steps.

MMFs in hand, we take the first one and start defining it further. This is where the information from the planning post comes in. We start to write stories (Cat has a great post detailing how to build effective stories). The other information gathered to this point sits dormant, with as little specification work done as possible, until such time as we are getting closer to working on it.

Over time, and only as needed, we put more and more specification on the system, and this is done in parallel with development. In fact, often the most specific information can only surface during development of those features, as they take shape, and as we understand how users will react. Specification should be every bit as iterative as coding.

Reduced to its essence, we JIT specification at many levels to allow maximum flexibility to change direction with minimal wasted work.

Gemba As an Essential Part of Specification

Lean has a concept of the gemba attitude and genchi genbutsu; essentially, being in the place where the action happens. Developers and business analysts have to work with the domain experts, in the place where the work happens, and observe the true workflows in place before hoping to design a system to support them. You cannot get this information from sit down meetings and emails with domain experts. You must go and see for yourself, or you will miss things.

It’s often the case that a team relies on "domain experts" to provide them with the specifications they need to build software. This is the BDUF way – gather in committee and have the all-knowing user tell you what to build. Fail.

My Experience With Gemba

Our dev team works out of the corporate office in Florida, while the actual laboratory is located in upstate New York. As a result, it is often an exercise of the imagination to figure out the best way to create things for them. Before I visited the lab, I relied on information from others, emails back and forth to the lab crews working all weird hours of the night, and my knowledge of the applications currently in existence. I really only ever got half the picture, and it was difficult to ensure that the things I was specifying would fit into the lab users workflow well without actually knowing what was going on up there. When I visited the lab my whole world was changed. Actually seeing how users interacted with the software and seeing ways they would work around what we didn’t have (open Excel or Word documents on their desktop, a wall covered in post-it notes). Just from walking around talking to people for 2 days, I probably got 50 requests. And they never would have asked for them; they would have just kept suffering. Being there showed me everything about how they worked and a million ways I could improve their lives. The experience was invaluable to both me and them, and each subsequent trip has just improved my knowledge of the way we work and the way they interact with our software.

                                                                                                            ~Cat

There is no substitute for a certain amount of domain expertise being resident in the team room. Your domain experts are experts only in their domain. They may know the workings of a histology laboratory inside and out, but if you ask them to design a system to support that lab, they’ll come back with something that looks an awful lot like excel and post-it notes.

Yes, this is real.  Yes, I died a little inside.

In the next post we will talk specifically about the tools and techniques we use to specify work, and how we combine them to form complete pictures of a system (spoiler alert: it ain’t just stories).

A big thanks to TheChocolateOne for sending us this story – anything can happen in Restaurant City!

My name is TheChocolateOne and I’m the head chef and owner of Massive Dynamics. Let me give you an inside look on what it takes to manage a restaurant.
My day starts pretty early as I have to open up to let my employees in. I’m running a bit late so by the time I get there, my staff is outside waiting for me to let them in. I have 3 chefs and I’m horrible at remembering names, so I just call them Chef 1, Chef 2 and Chef 3. I’m usually the one shouting, “hey! Chef 3! What’s taking so long on the Royal Garden Salad?” I also have 4 waiters, and all of them are great at what they do.

As we’re getting to our stations, the first customer arrives – ah, it’s Sam. He’s a regular here at our restaurant. Sam’s usually here for breakfast, lunch, dinner and sometimes he’ll stop by for a few cups of coffee in between. Basically, he’s here all day!

“Sam, nice hat,” I point to the cheese on top of his head.
“Thanks,” he replies, “just bought it. Wait, where are the toilets?”
I laugh, “they’re over there”.

Sam looks over to where I’m pointing and breathes a sigh of relief, “thank goodness! You’ve added dividers!” He leans in a bit and says, “it’s was a bit awkward the way you had it. Y’kno, the chair – toilet – chair – toilet…” He sits down and says, “whip me up a Tuna Sushi!” Chef 1 shouts, “yes, sir!”

Throughout the day, we have a lot of people coming in and it’s always busy. At one point, one of my waiters comes over and asks, “sorry to bother you Chocolate, but can I take a break?” I freeze up and reply, “absolutely not! We’ve got people to feed! We only take breaks if no one comes in! Here’s a sandwich.” Around noon, Chef 2 checks on the garden outside. I’m desperately hoping that one will turn out to be sugar but when he comes back he shakes his head in disappointment, “this sugar drought is horrible. No sugar for miles!”

I decide now’s a good time to check out the Market so I ask two of my waiters to push the arcade in front of the door. “We only have 2.6% stamina left! I don’t think we’ll make it,” they groaned. I told them that this business isn’t for everyone and that there are always people wanting to experience working in a restaurant. Translation? Work or I’ll sack you and hire someone else.

At the market, I take a look around. Cream for 2500, ice cream for 4200 and basil for 3600. I really need cream but seeing as how I’m the only one here, I take a chance to talk to the seller, “psst, listen, I’ll keep it quiet but just tell me one thing – will sugar be on the market later?” He glances around him and whispers, “sorry, friend. You’ll have to find out – later”. Well, can’t blame me for trying. I purchase 4 creams and as I’m walking down the street, I hear screaming in the distance. Oh no, I thought, that sounds like my staff! I drop everything I’m holding and run as fast as I can.

Bursting through the door, I see a rogue squadron of penguins.
“Eek!” My waiters are screaming, standing on top of the Elegant Chairs.
“No!” I shout, as I realize they’re leaving footprints on the new items I just bought.
Chef 3 says, “don’t worry, boss. I’ve got this…” She runs around looking like a maniac with a net, but manages to capture the penguins. “Phew,” she sighs, “good thing I used to work at a zoo.”

After peace is restored, I realized I dropped my creams. I go back outside – but they’re gone! There’s a note on the ground and I pick it up. Somebody wrote:
“Thanks for the cream! I’ve traded you some sweetcorn.”

I look down at the pile of useless sweetcorn and gather them up, feeling dejected. Back at the restaurant, things are running smoothly again. I throw the sweetcorn into the storage room and take a moment to look over some of my ingredients. 2 creams left, 5 pumpkins, 7 basils, 86 sweetcorns and yet… no sugars. I looked up at the ceiling and prayed to the sugar gods, “please! Let there be sugar! I’ll do anything! I’ll…I’ll…dance! Yes, I’ll sing and dance if you just give me sugar!” So, listening to the music playing in my head, I start swaying to the nonexistent music like a bendy straw in a tornado. That’s when I heard, “ahem…uh..boss? We need you out front….” I turn around and one of the waiters is staring at me with a look that can only be described as this: O.o

“Er…uh…ahem. Not a word to anyone,” I stutter. She replied, “I won’t say anything. Nice moves though…”

I rush back out and take up my stove, cooking the Chili Con Carne in record time.
Eventually, it’s time to close up for the night. It’s really amazing how fast the day goes by. As I say my goodbyes to the cooks and waiters, I lock up and walk home, getting ready for tomorrow – another day in Restaurant City.

I wrote earlier about using agile software reuse and the key ingredients that are beneficial when pursuing such a strategy. In this post, I want to summarize how agile practices can be used to build reusable service capabilities.

This isn’t an exhaustive list of agile practices that facilitate reuse – consider these as a starting point.

Like this post? Subscribe to RSS feed or get blog updates via email.

Before I begin, I’ll issue a warning: What you are about to read is not advisable, though it is a first-hand account.  (Also, I wish to credit Scott Sehlhorst for inspiring my commentary by his comment about this topic in this post about agile prioritization.)

I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.

Now that I have that out of the way, a little background.  The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts.  Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough.  So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception.  To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.

Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.”  The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product.  In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story.  In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough.  We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.

From a higher level, there’s another lesson here that operating under both paradigms has exposed.  It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action.   Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.

Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.

An additional benefit of having more interaction with a client is having the chance to manage client expectations.  When we first meet the client and start beginning to understand their needs and requirements, we should try to clarify and understand their expectations.  Client expectations can take many forms.  They can have expectations about how their landscape will look, how they will use the space, how long it will take to make the transformation, what it will cost, how the process will work, and on and on.

Initial client meetings should address some of these expectations.  You can explain the process, timeframes, and many other questions.  Some of their expectations such as how the design will look, cost, and so forth will have to wait until further into the design process.

In the early stages, the biggest concern is identifying unrealistic expectations.  The client may have a picture in their mind of what they want that just will not work in their space.  They may have unrealistic cost expectations.  They could have expectations of their space being able to accommodate many more guests than is realistically possible or plant types that will not survive.  These types of expectations have to be caught early and reset to a more realistic level.

As you proceed through the analysis of your client and site data, you can begin creating some of the visual presentation tools that I have mentioned.  When you use these for client feedback and discussion, you are also giving the client information that will help level set and manage their expectations.  This can also reinforce things you have previously told the client.  For example, if the client had expectations about the size of the planting beds that you addressed early on, it would be a good idea to present a visual diagram showing how the space will be utilized in the best way.  This will further reinforce the new expectation.

The keys to managing client expectations are first, early identification of what those expectations are, and second, managing those expectations to the correct level through discussion with visual presentation from your analysis.

I have made numerous comments about the importance of creating a client experience in the design process.  I will try to explain why I think this is an important effort and why it adds value.

As consumers, we purchase at four levels:

• Disposables / Consumables – gasoline, tissue, food
• Products – televisions, music systems, appliances
• Services – design, medical, legal
• Experiences – that intangible “thing”

Within these categories there can be combinations and value-added.  Here are some examples.  Gasoline is gasoline except when the oil company offers different grades of fuel or tells you that their fuel as a super performance additive.  Gasoline begins to take on some of the characteristics of a product.  Tissue is tissue except that most of us ask for a Kleenex.  The product has become synonymous with the brand.  A music player that connects with a streaming music service has value added beyond the product because of the underlying connection to the music service.  The automobile with a built in connection to an emergency service has value added beyond the automobile itself because of the sense of safety and convenience the service provides.  We could go on with numerous other examples.

Experience comes into play at just about any level.  We may think of experience as something that we truly feel or live through such as travel or a concert.  Experience does require a human element.  An experience should be produced by something.  It may be visual, tactile, auditory, or appeal to any and all of the senses.  It should last some period of time.  How long will vary.  It should be memorable and powerful.  An experience should engage the person.  It may be passive, the colors or textures in a space, or it may be active such as the hidden bend in the walkway.  Lastly, the experience should extend or enhance the value of something else.  That hidden bend in the walkway that leads to a peaceful retreat adds to the value of the walkway.

In the typical landscape design project we have the disposable / consumable items such as mulch or annuals.  There are products such as the furnishings or outdoor kitchen components.  There are services such as the design, installation, and maintenance.  The experience has to be created in addition to these physical and service components.  The question is how.

I believe it fundamentally means starting with the context.  What are the characteristics, issues, and opportunities with the site itself.  Who is the client; what are their needs and values.  This context is going to create a gap between the existing situation and the design concept.  This gap, which is what the analysis is all about, will help you determine what experiences can be created.  I think this is where personas,  scenarios, and user stories can be very important.  They can help us visualize what those experiences can be and how they fit into the design concept.

Creating the experience will come from adding to the design concept in ways that impact those who will visit and use the space.  Some of the characteristics I mentioned before have to be added.  You have to add to the design environment the thing or things that will be memorable, powerful, and engaging.  They have to affect and impact people.  They have to last some period of time.  The intangible “things” you add to the design concept create the experience.  The experience concept extends the design concept.

Megan and I returned to San Francisco last week. We have started the process of unpacking all of our observations in order to start incorporating all of the feedback we received into the Pepper Eater’s design. Yesterday, with the help the d.school’s Erica Estrada (she is starting the Social-E Lab at Stanford), we filmed a quick video to update our funders on the progress we’ve made so far. We tell a couple stories from the trip, so check it out!

A few days ago I had the chance to meet with an architect who uses Bluebeam. She gave me a lot of insight into how she uses Revu, and I spent the entire time feverishly typing notes. I may have even given myself a mild case of carpal tunnel. But no pain, no gain – right?

Anyways, one of the features she pointed out is File Attachments.  She uses this feature to attach PDF copies of RFIs onto her record sets.

Attach your RFIs to your PDF record set to keep track of where in your building there were questions.

You can use File Attachments to append any file type to a PDF, such as images taken on a jobsite. You can also choose what icon you want Bluebeam to use to represent your File Attachment: A file icon (which updates depending on the type of file attached), a graph, a paper clip, thumb tack or a tag.

When you hover over a File attachment, the file name will display in a pop-up. And, when you double-click the file will open either in Revu (if it’s a PDF) or the appropriate viewer for that file type (i.e. Excel for an .xls file attachment).

What a great way to keep track of project RFIs!

See, I told you File Attachments are cool! So go ahead and use them, and remember to keep on PDF’ing!

-Karen

Bluebeam has a reputation, and we just can’t shake it.

Last week I posted some comments from people who think we’re easy. This week, my coworkers in Account Services sent me some more easy feedback:

“Bluebeam is an easy program with ample features.”
-Bruce

“Bluebeam worked great. It was easy to load and everything went without a glitch.”
-Michael

“Bluebeam is very powerful software that becomes easier to use the more you play around with it.”
-Fred

What do you think? Let me know. And remember, to keep on PDF’ing!

-Karen

I kid you not, a few days ago my coworker Michelle forwarded me this comment from a Bluebeam user:

I have only just played with the program but I do think Bluebeam is the best thing since sliced bread.

- Mark

What do you think? Is Bluebeam to PDF editors as sliced bread is to baked goods? Let me know. And remember, to keep on PDF’ing!

-Karen

Remember to keep sequential numbering in place and please don’t comment or add a new blog with the user stories category. Rather, just edit this posting.

1. The user will be able to identify their current location by a graphical icon located on the map.
2. The user will be able search for a building by name, number, or course number using the on-screen keyboard.
3. The user will be able to touch a building found in search (story 2) and have it highlighted on the map.
4. The user will be able to highlight all buildings matching a category by touching one of the category buttons.
5. The user will be able to highlight a building by touching it.
6. The user will be able to highlight most frequently searched buildings by touching the “Frequently Searched” category button.
7. The user will be able to unhighlight all buildings and clear the search field by hitting the “Clear” button.
8. The user’s highlighted buildings and search field will be cleared after 60 seconds of inactivity.
9. The user will be able to touch “Get Directions” in the pop-up window after highlighting a building and see textual directions on the right-side of the screen as well as a highlighted path from the kiosk location to the building.

It seems that Bluebeam has gotten itself quite the reputation…for being easy.  Just take a look at what our users have been emailing us:

“Bluebeam has made reviewing documents much easier without having to go back and forth between numerous programs.”
-James

“I didn’t think I could find something better than Adobe Acrobat, but Bluebeam is easier to use and fits my needs much better.”
-Teresa

“I am pleased with Bluebeam’s ease of use.”
-Roger

“Bluebeam is very easy to use…now all I need to do is convince my boss that I need it!”
-Jodi

Do you think Bluebeam’s the easiest PDF editor on the block? Let me know. And remember to keep on PDF’ing!

-Karen

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

- If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

- So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project