When you work as a Business Analyst, important part you job is to conduct software demos and software reviews with users. User reviews can help a lot to improve quality of your product, but you need to put some effort to ensure efficiency of reviews. Here some some hints on that will help. First and foremost, you go on those review session to hear users' feedback, positive and negative. You want to make users tell you what they like, what functions seem to be overly complex, where performance is not up to par. You do not conduct reviews to impress users, to have them breathlessly admire features you demo. You have to come to those reviews with the only desire to hear your users and make your software even better for them.

Be prepared to hear negative feedback and do not try to defend the approach you took to implement certain feature, when users say they do not like it. If you try to defend people will immediately feel that they are wasting time with you, because you do not care about their feedback and insist on you solution, when they call it wrong. Instead, you want to understand, why they think it is a bad approach, and then propose a solution to that. Audience will appreciate your care.

Make sure that your own feedback and comments were addressed before you show anything to users. Nothing can be more frustrating on the review than hearing something that you already know. At least you need to make sure that review participants are aware that certain areas of the product you review fall out of scope of today's session and they should not pay any significant attention to any gaps there.

Keep audience engaged during the entire review session. When someone makes a couple of comments, he feels like his mission here was accomplished and, as a result, will be less attentive, less willing to interrupt anybody to propose idea. You want to keep everyone in the game, and some tricks from presenter's toolbox can help you with that.

Great talk by Dan Pink at TED about pitfalls of extrinsic stimulus and scientific evidence for intrinsic motivation:

I kind of always felt that way, but now I've got evidence to refer to. Plutarch was right that

The mind is not a vessel to be filled but a fire to be kindled.

You can not stimulate creativity, you can only create environment for it to blossom.

Sounds familiar?

Failure means distrust. Distrust to you about delivering on your promises; distrust in your ability to make a difference; distrust in you taking care. Basically, it is as simple as:

1. Drawing attention to a problem without communication of causes and planned corrective actions.
2. Repeating the same error again (when you do not change anything after step 1).
3. Making problem a habit, when it happens for the 3rd time. Now it is clear for everyone that you do not give a heck about what's going on.

After step 3 there is almost no way to recover.

At the resort I stayed with my family for a vacation, we had breakfast served at 8:00 am. The first time a crowd of about hundred people had to wait for extra 10 minutes till they started serving, I remember my thought "Can happen. Probably, they wanted to please us with something special and underestimated the time."

Waiting in the crowd the next day I thought "Something went terribly wrong here. There must be a serious challenge involved at serving at 8 am."

After the third time nothing could make me come to breakfast at 8 am. I knew they did not care that we all had to wait for 10 extra minutes in a crowded room. I had to find a solution for myself and I did! Thereafter we came to breakfast 10 minutes late. In other situations, when your customers have more flexibility, they will simply quit your service. They will not do that because  there are issues, but because you do not care.

Take care to fix issues your customers face.

I was amazed when I saw this video. Object removal is especially impressive.

And it seems that you already can use similar technology in graphics and imaging products. Check out this Photoshop CS 4 tutorial and Liquid Rescale GIMP plugin.

For this weekend we'll get some reading on the topic of requirements in Agile:

• Writing Good User Stories. Nice concept of INVESTing in user stories.
• Latest description of FDD process. Pay attention to step 2 'Building a Features List'. Apart from precise definition of what a feature is, it introduces an interesting idea of time-boxing for features: a feature should not take more than 2 weeks to implement; if that's not the case - break it down.
• Why I still use use cases. Alistair Cockburn on what can be wrong with user stories.
• Writing Complete User Stories. Nice guide on how to address often perceived problems with user stories.

Toy Story 3. Release date: June 18, 2010. 323 days from now. Does not that amaze you? No? Most likely you are not a Project Manager. And certainly not a software Project Manager.

In software world we know how hard estimation is. And to date I have not met a Project Manager, who would commit to a delivery date a year from today. Well. one can commit, but what about keeping this commitment. Recently Boeing postponed first flight test for its Boeing 787 Dreamliner till early fall. This might not sound bad, but what if originally this aircraft was scheduled to take off in 2007?

Surprisingly, in entertainment industry they know how to give promises and keep commitments (at the very least with release dates). How do they do that? I do not know for sure, but my take is that the "secret sauce" should be in very effective scope management. And, of course, expectations management.

When film is announced not more than title, broad story topic, and, probably, some of cast is told out. More details are given out to feed public's interest, but I bet they never tell us about something that can not be done by release date with high degree of confidence.

There is certainly something to learn from this approach.

Last weekend we kind of explored the field of software estimation, so it is about time to see, why it is not an easy task. Complexity is what makes estimating hard.

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

-- Jerry Weinberg, Quality Software Management Vol 1, Chapter 9

And here are some more links to explore the topic:

• The Rising Costs of Software Complexity 2001 Dr.Dobb's article.

What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity.

• No Silver Bullet: Essence and Accidents of Software Engineering by Fred Brooks.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

• Recent NASA Study on Flight Software Complexity (via Glen Alleman).
• Code's worst enemy by Steve Yegge. A practical view on software size as main contributor to complexity.
• The Fourth Law of Software Design: Complexity vs. Ease of Maintenance. Another practical report, which discusses how "an average-sized computer program is so complex that no human being could comprehend it all at once in their mind" and what effect it has on software engineering practice.

Did not I told you that multitasking is evil? Gauge your distraction to see it yourself! Multitasking is like using "all seasons" tires: they drive equally bad in summer and in winter. When you multitask, all of your activities end with equally bad result.

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

• Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
• 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
• Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
• Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
• Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.