Better Projects

What is a User Story

2012-02-02T08:00:00.000+11:00

I have been at Wikipedia again. This time at the User Story page. I didn't like the contents as usual, and this time I drafted a variation on the Wikipedia page and published it in the Business Analysts Handbook. A copy is recreated below for your interest. It also serves well as a first post in the Agile Thursdays series.

Introduction

A User Story is a marker indicating a request for work to be done.

User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.

Important things to consider about User Stories

They are a token for doing a piece of work and are not a software requirement in the traditional sense
They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas
A User Story is likely to evolve over time as people's knowledge on the topics area matures
Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available
User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication .

Card Conversation, Confirmation
The three essential elements of a User Story are the card, conversation and confirmation.

These are described below under the following headings.

Card = Physical v Electronic
Conversation = As a Product Owner I want a template
Confirmation = Start with the end in mind

Physical v Electronic
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.

Many teams also capture User Stories in electronic media such as requirements management or test tools.

There are many purpose build product backlog management tools on the market.

As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

As a [user type]
I want [an interaction+outcome]
So that [I get some form of value]

The benefits of this templated form are real and tangible. An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.

Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.

But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.

Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated. From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;

Given
When
Then

Where given describes a starting state, when describes a trigger or catalyst and then describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.
Further reading

Related topics

INVEST - A quality checklist for User Stories
Kanban - another concept for work tokens
Story Maps - a way of managing large numbers of stories
Behaviour Driven Development - Test thinking applied to stories
Stories as Inventory - understanding the cost of too many stories (or requirements)

Agile Thursdays

2012-02-01T08:00:00.000+11:00

I thought I might try something different with my blogging: A structured approach.

In the early days of this blog I was exploring and discovering techniques and models from the engineering paradigm of project management and requirements. I learned a great deal of useful stuff, some of which is re-emerging now as part of the Kanban movement. Given there is so much interest out there in the agile thing I thought I might try a regularly and specifically themed agile blog.

I'll be drawing the post topics from the local Agile meetup groups. Their goal will not be to give definitive answers on topics, but to raise awareness and to provide a platform for further investigations. I hope they are useful.

If you want to see a summary of all the topics covered to date try searching the blog for "Agile Thursdays."

Better than a Requirements Template?

2012-02-01T06:51:00.001+11:00

Check lists beat templates hand down. Checklists say "Have you done enough?" They help you think through the issues.

And they can become mindless activities as well. Checking the box unthinkingly, or adding new items to the checklist without ever taking the time to trim some unnecessary items.

But I reckon they are still better than templates. They are definitely more lightweight.

I just created a checklist to help someone with little project experience think through their project needs. Take a look. I'd appreciate some feedback.

End to end analysis framework

It's not perfect. It's not even complete, I'd say. But how would it stand up as a newbie guide?

I don't believe in slipping dates

2012-01-30T09:00:00.000+11:00

You're in the weekly project status update meeting. The agenda has been reviewed. Last week's minutes are quickly discussed. The PM asks for any new business and finally its time to do that last task we all dread...

Review the project schedule.

The PM opens up MS Project, filters by task end date and asks everyone in the room for a status of the tasks that will end during the next week. Its a painful process, takes at least half of the meeting and most everyone is checking email while their colleagues provide updates.

After all the updates are added to the schedule, the PM asks Project to calculate a new end date, only to find that the project just slipped two weeks.

Oops.

Now the PM goes into panic mode. How did this happen? We were ahead of schedule last week and now we're going to be late! Where is the slack time? Who is on the critical path? Can we crash this thing back to baseline?

The sky is falling!!!!

Or is it?

This situation has always bothered me in ways that I never really could put my finger on, but this week I think I finally understood why this bothers me so much. While on my commute, I was listening to the Back to Work podcast, featuring Merlin Mann and Dan Benjamin, and the topic focused on projects and slipping dates. Merlin's main points were not directly related to my epiphany, but it did get me to thinking some about the whole concept.

Here's the deal... I don't believe dates ever slip, no matter what happens in the project plan. Dates are fixed, and not just because some executives says so. The day a project is over, with whatever system or process changes implemented, is the day it was done. It doesn't matter if that day was weeks early or years late, that is the day the project finished. You can't go back and change that date and since it is now live, you can't go forward in time and make it go live again (at least not with that particular phase).

End dates are always fixed, but what isn't fixed is our understanding of that date. Its possible, maybe in probable, that at some point during the project, something will come up which alters our perceptions of the project and how close we believe we are to its end.

The end date did not change, only our ability to accurately see that end date.

Big deal, you say, the effect is the same. That is true, but I believe that understanding end dates in this way changes our perception of projects in general.

If dates 'slip', this is seen as a bad thing; like we're not doing our jobs or that something unforeseen has impacted the schedule in a way that is not easily recoverable.

If my view is correct, then new information has been assimilated and we now have a more accurate picture of reality.

I don't know about you, but I think my viewpoint feels a lot better.

The terror of the templates

2012-01-29T22:56:00.003+11:00

This sat in draft for a while. It's about bureaucracy, PMOs and change.
Some quick questions to get you involved;

Do you know the people in your PMO?
Do they know you?
Are they committed to seeing your project succeed?
Really?
Or are they just about process compliance and weekly status reports?

Some PMOs are really useful, some are less so.

(PMOs are a nebulous thing, so I might run up another post on my views on what makes a good PMO at another time.)

I recall once I had to go into a meeting where I had to justify why I wanted to create addional project documents, and why I wanted to vary from the usual tempaltes.

The reason I wanted to do 'extra' documentation is becasue we want to demonstrate new processes and methods for the organisation, and as a result want to keep them comfortable while w experiment with their people and processes.

We'll follow good agile practices and do fortnightly product reviews, and product burn up charts, and we'll also provide a report showing time and money spent against a target. We'll work with a backlog full of user stories, and we'll also provide a high level requirements summary for our main release phases, one at a time, focused on the next release.

We definitely want to present a Project Management Plan, and a Quality Plan and Communications & (people) Change Management Plan which aim at explaining our methods and thinking through some of the more complicated parts of the program.

So, if I want to go above and beyond in terms of project documentation why the hassle?

Well, for one thing I also want to omit redundant documentation. In particular some of the requirements documentation. We already have plenty of detail to hand, so why both rolling it up into multiple summaries and decompositions? We already have a product vision statement and release roadmap so why elaborate that into additional documents that are at the heart of many project failure modes.

And while I am on the topic of reducing overhead, I would really like to abandon the template approach to documentation. I get the point of templates, and in the past templates have helped me learn, but checklists are a much more effective tool than templates and make for less overhead

I specifically want to abandon the parts of templates that repeat the same shot over and over again so the repetitive and incidental details can be cleared out of the way, and so that important information can be added. Remember white space? I want a crisper and clearer message. I want the readers to engage with the content.

Picture of the PMO manual care of Celeste CC @ Flickr

All Models are Wrong (Part 1)

2012-01-27T15:18:00.000+11:00

You've heard the phrase "All models are wrong: Some are useful," by George Box, a chemist who taught himself to be a statistician. My takeaway from this is that all models - and that is everything written down in all management texts and training manuals everywhere - is that the model is a lens to look at a problem through.

When I was an undergraduate at university studying marketing we were discussing the Marketing Mix. "When launching or developing a product..." the lecturer said, "pay attention to Price, Promotion, Product and Place..."

I sat there thinking. I didn't have corporate experience and this didn't make sense. It just seemed to simple and to pat. (Four Ps!) I was trying to learn this stuff by applying it to the bar and restaurant jobs I had.

How can I apply the four Ps to the restaurant? We can't move it, especially me as a waiter, so the distribution aspect is a moot point. Maybe we can change the prices and the menu (product) and sure we could do something to raise the bar when it came to promotion. But what about the other aspects - the relationships the staff had with each other, the way we interacted with the customers, the suppliers (especially the alcohol sales reps!)

So I said as much to my lecturer; "This doesn't seem to be enough. Surely you need to think through more than this to launch and manage products."

It was then I got one of the best nuggets of information from that degree.

"It's just a checklist to help you along. It doesn't give you all the answers. You have to use your brain to solve complex problems."

I wonder how he remembers the conversation, if at all.

I Called It!

2012-01-24T08:00:00.000+11:00

Back in June of last year, I wrote a post entitled A new Facebook Use Case where I suggested that what FB really needed was a translation utility for comments. Called it.

Obsession Times Voice

2012-01-19T13:14:00.002+11:00

One of the members of my QA team recently said something about me that made me smile. It wasn't that the comment was some kind of over the top suck-up or a snarky jab, but something that was a subtle reminder, in the midst of a sentence on an only vaguely related topic, of why I get up and go to work every day.

He said I was the only person he knew who loved their job.

The sad part is, I don't think he's far from wrong. I do work with several people who I know do love their jobs and it is clear from my daily interaction with them that their passion for what they do comes through in every conversation, every email and every line of code.

Its people like this, those who think of what they do as craft, who inspire me. I'm lucky; in my current job, I'm fortunate to have many of them who work with me. In my career, I've worked with people who are all over the spectrum when it comes to intelligence, motivation, perception, knowledge, wisdom and taste, but rare has been the person who really has a passion for what they do.

Passion is fleeting, but when it is really intense, its something that has you and not the other way around. Its something that I don't think you can fake; its either present in what you're doing or its not. The quality and the responsiveness of your work is directly correlated to exactly how passionate you are about it.

Even though I crossed the line years ago from individual contributor to manager, I still make it a point to regularly go back and do some business analysis work just to keep my skills sharp. Strangely enough, every time I sit down to do a bit of light analysis on a project, I can't help but remembering why I love this kind of work so much, why it fits me so much. Simply put, I get to make a difference for someone (or as I am fortunate enough to do, for millions of someones).

Given that passion, it probably shouldn't be a surprise to any of you that I obsess about projects. There isn't a better way to illustrate this than to realize that for two years (minus the last 4 months), I've been regularly writing on this blog. That isn't easy, especially with a crazy workload, long commute, a 2 year old and a small bit of socializing. Obsession over this topic is something that drives me, not the other way around.

Obsession is a powerful thing that John Gruber and Merlin Mann nailed. Listen to the audio in the link on this page as these are two guys who really understand what it means to take obsession and give it voice. Their obsessions are different, albeit related, to mine and I strive to have a voice that is as strong as theirs. In particular, pay attention to Merlin's discussion of writing about Jawas. Brilliance.

One of the things writing on this blog has helped me with is to find my voice. The last couple years have helped me refine what I really feel is important in a project and the direction I think projects will take in the coming decades. Technology, especially in the mobile space, stands to make a radical shift in how we elicit, document and analyze requirements.

The biggest change, in my mind, will be using video in the requirements process, especially agile processes. We can already do this today, but mostly its done by making some kind of prototype or slide deck, narrating over top of it and letting your remote users get a feel for what it will be like to use some kind of application. Pulling all that together into a produced video takes lots of time and planning. I don't think this will be how we do it in 20 years.

I see our business users watching someone failing at a process, pulling out their pocket communication devices (we better not be calling them phones then!), snagging a video of the incident, tagging spots in the frame, adding some text or commentary on top of the video, emailing it to the project team and waiting a few hours (better yet, minutes!) for the adjustment to the system to be made.

Or how about the stakeholder using that pocket communication device to make the adjustment themselves! Instead of creating only the tool used by the person performing the process, why not create the next great app that is used to create the next next great app?!?

Its ideas like this that really get me excited. My obsession is going full speed and my voice is coming along. I hope you all can say the same.

What is the Origin of the term "Functional Requirements"

2012-01-12T17:32:00.003+11:00

I have been over editing Wikipedia again. This time on Functional Requirements.

Yes, it's the poor quality that revolves around the Requirements and analysis topic that drew me in. Wikipedia's content in this space is a classic example of the plumber with leaky pipes syndrome. Each time I see it I just can't help myself. I have to edit.

But this time I am stuck.

My question for you dear reader is this;

Where does the idea of the Functional Requirement (as opposed to just a plain ol regular requirement) come from? What is the origin story of this mystical term?

And while I am here, can you share your view on what the essential elements are that make a requirement "functional?"

Thanks in advance,
Craig

Stakeholder analysis

2012-01-11T16:53:00.001+11:00

Stakeholder analysis tends to be an underdone activity in most projects. There seem to be a number of reasons for this including social and technical ones.

Next month we are going to have a lunchtime session at work on stakeholder analysis so I did a little research on the topic and came up with a list of useful ideas. They are posted below with some links.

I am thinking about:

What does stakeholder mean?
What boundary conditions help define who is and isn't a stakeholder
Why analyse stakeholders?
Techniques for identifying stakeholders?
Techniques for analysing stakeholders?

Frameworks & thinking models

The power/influence matrix
Mapping stakeholder via KRAs
Ranking stakeholder needs
Networks of influence among stakeholders
Integrating different analysis models
The stakeholder circle model (more examples) from Mosaic

Case study: Visualise workflow

2012-01-03T15:31:00.000+11:00

James led a project team that was to investigate and address improvement opportunities for the online sales channel for a financial services organisation. The sales process was mapped and charts put up on the wall of the call centre, where most of the back office work was done.

Subject matter experts from the call centre were asked to inspect and comment on the chart, and to nominate suggestions and improvements. The analysts stood back and made o recommendation. Their contribution to the conversation was to elaborate and explain the diagrams and their notations, and to make corrections as frontline staff observed variations between the model and reality.

The operators identified several bottlenecks and activities that yielded little more than customer or staff frustration. The analysts captured the issues and documented them, later reporting them back via updated models.

By the time the documents had arrived two weeks later the frontline team had already taken action to streamline their process and optimise it for customer experience. Sales had already risen and without any further action the project could well have been called a success.

Understanding Bureaucracy

2011-12-08T20:35:00.001+11:00

Bureaucracy is a form of organisational structure. It is not the paperwork and busywork we see in large organisations. That is something different. It is waste, inefficiency and an inside out view of dealing with customers.

But they seem to go together, don't they?

In the next few weeks I want to go through some of the ideas about what a bureaucracy really is, where it came from, what it's strengths and weaknesses are, and what we should do with it when considering the design and creation of new workplace systems and structures.

And why is it they are so frustrating to deal with?

Here is a tentative roadmap for the discussion. I'll update it with links as I write the posts.

What is Bureaucracy
Origins of Bureaucracy
The Evolution of Bureaucracy
Organisational theory on Bureaucracy
Alternative Models for Bureaucratic Organisations
The future of Bureaucracy

Case Study: Problems with Estimating

2011-12-06T15:20:00.000+11:00

On an application development project I had problems with estimating the details of software projects and managing feature creep. We were tracking okay to the high level estimates we had put together pre project, but on a story by story there was very little accuracy in estimates.

As we know from Kailash's blog post delphi planning (e.g. planning poker) amplifies estimating capability. If your skills are good, the group approach makes it better. But if your skills are poor you'll just amplify your error rate. We seemed to be stuck in the second category.

Watching the cumulative flow and cycle times on stories gave me the right cues to take information to the plan with a recommendation. I could see the average story size was also the threshold for estimates breaking down. So, on average the effort to fulfil a story was going to vary substantially form the estimate. The threshold was a story of about 5-6 days of effort.

I put it to the teams that we target a 2 day maximum effort story size as a threshold, and if stories were larger we break them down further until they fit into that threshold. This was generally accepted (but not consistently applied.) The additional effort in breaking down stories increased flow and yielded improved results (which still needed further improvement.)

My role was in the analysis of the team’s performance data and linking the problem of large stories with size limits. The team were able to adopt this change and the positive results were shown in future performance reports.

This led to me generally advocating the “count the stories” mantra alongside the Kanban method community. I’ve also combined it with the Requirements Traceability technique to good effect. (see more here.)

Why you guys suck at estimating

2011-12-03T20:38:00.001+11:00

Kailash wrote a great blog post on estimating. It gives the maths behind why you guys suck at estimating.

Go read the post here.

Kailash tells us that essentially your success at estimating is amplified by doing it Delphi (blind group) style. This includes Mike Cohn's planning poker approach to estimating.

That means that your estimates increase your capability if you get many people involved. Unfortunately, if your team's average estimating capability is poor you'll be amplifying poor estimates (ie moving further away from the eventual truth.)

His post comes with disclaimers and it would be neat to test this out with some experiments, but it is one of those ideas that 'feels' right.

This post is my response to the ideas he presents and some additional thoughts on the problem of estimating.

It's timely for me right now because I have been doing some estimating work for my team's 2012 portfolio and I have been pretty much ignoring all recommended best practices for estimating and instead guessing most initiative sizes using my instinct.

What makes me think I should be doing this rather than using a consultative, and in particular a Delphi approach to estimating projects?

Why am I more reliable than many other people who have worked here longer?

First and foremost I believe that most in our team are not particularly competent at estimating. So I trust my judgement more than theirs. I've been around and educated myself about estimating. I have also been around and gotten a feel for how much effort things both 'should' and 'do' take in organisations of various maturity. I have a breadth of experience.

Additionally, in my current estimating work I looked back at historical performance and looked at sizing next year's projects against last years. This gives me a feel for the capability of the organisation. Relative sizing works for me.

Additionally I don't actually do it alone. I have asked others to estimate in some instances. But again I have gone to individuals rather than the whole team that is to do the work. (Some teams aren't even hired yet.)

So Kailash's post gives me confidence hat I am not doing something stupid and there is some theory that stands behind my instinct to keep the estimating activity to a small group of people.

There is a better way.

You may suspect that better way could be developed by giving everyone experience participating in estimates so they can build their competence. We could do that, and should for a handful of people for the occasions we do need to estimate things.

The better option is to gather historical data and use that to forecast the future.

In the course of next year I'll be working the team to gather data so we can get better historical numbers. In the next annual planning cycle I hope we'll be 'counting cards.'

Dave Gray on Gamestorming: Design Practices for Co-creation and Engagement

2011-12-01T15:35:00.001+11:00

Dave Gray talks on using games to help design products and work. A key point I liked was that by involving users and clients in the creation of products (and knowledge artefacts like user stories and requirements) you get them championing your project efforts in a much more engaged way. Enjoy.

Product pitching vs software requirements

2011-11-19T13:38:00.000+11:00

I was recently in a competition which involved doing a 60 second elevator pitch to a panel of judges, and learnt more than I expected from the experience.

My first main takeaway was the amount of effort required to really crystallise into just a few words the problems which I was proposing to solve. Expressing the problem is the absolute kicker in a product pitch, but it also made me reflect on my BA work. The standard requirements template I work with every day has a 'business need' section under the title. It can be easy to get lazy with that and just basically restate the requirement title in more words, rather than go that step further to actually capture the essence of the problem.

Likewise within the standard user story format, what follows the '...so that' component should really hit home to help everyone understand the value of what we are setting out to achieve. A nice metaphor that was passed on during one of the competition pitching workshops was "put your listener/reader 'out in the hot desert' with your problem description, so by the time you propose your solution they are so thirsty they're willing to pay $1000 for the glass of water you are offering!".

The second takeaway stemmed from standing in front of actual investors and feeling the potency of the situation - I'm asking these people for cold hard cash and they need to be convinced of the financial return they'll receive on the basis of this idea/solution!

This experience has given me a new perspective. Sure, my project stakeholders aren't usually dipping into their personal finances, nor are the risks as high as funding a startup idea. But still, there are stakeholder's professional reputations and real money on the line. As a BA I need to play my part in making sure that the problem actually exists, it has been properly analysed and captured, and that measurable value is delivered at the end of the day.

Embracing Constraints

2011-11-18T09:00:00.000+11:00

Whenever you hear the word 'constraint', your mind is probably like mine and you picture a set of handcuffs. You want to do something for your stakeholder, but because of some limitation, you are unable to deliver to them what they really need.

If you're passionate about what you do, this likely frustrates you. What you really want, more so than anything else, is to exceed their expectations, delivering them the most perfect solution in the world. When you are unable to do that, you probably feel some resentment, not toward your stakeholder or yourself but to whoever imposed that constraint on you.

But it occurred to me during my drive home today that maybe we've all got the wrong image of constraints in our heads. Maybe, instead of bemoaning the limitations that constraints put on us, maybe we should learn to embrace constraints as a good thing. Don't believe me? Lets think about a couple types of constraints and see if a shift in viewpoint could change the way we approach a situation.

Lets say that one of your company's rivals just released a spectacular new product that has instantly made your company's products look obsolete. The finance team has done a few calculations to show that revenue projections will slip by 25% by the time your next new product is released that will return the market to its previous parity. Your product development team has started on a project to create that new product, but is months if not more than a year away from completion.

At this point, you've got a problem. Marketing suggests changing the target market. The sales guys are in favor of slashing prices and moving more units. The production group screams in protest; that they can't keep up with orders now, much less at larger volumes.

You're asked to figure out what could be done to keep the company going until the next big product is done.

First, you recognize a time constraint. The project team needs a year to get a totally new product out to market; one that will, you hope blow away your competition... but your company doesn't have a year to wait. The right question to ask in response to this type of constraint is what can be accomplished quickly that can, if not return the market to parity, to at least get your product to be more competitive.

Its time to start looking for easy options: change the product's color, add in cheap bundles to increase the value of the product, look for opportunities to co-market the device with related products. In short, its time to start thinking of what you can do within a reasonable period of time and not what you can't do with all the time in the world.

Next, you recognize a cost constraint. If finance is projecting such a dire sales slump and your company doesn't have the free cash to keep running at the current cost structure until your new product can turn sales around, its likely you won't have the staff or budget to finish that project in the projected year. If your company cuts staff, the project will take longer. If the budget gets cut, your quality is likely going to suffer.

One way to combat a cost constraint is to figure out ways to mitigate the loss in sales. One way to do this is to offer incremental improvements in your current product that can be delivered in a very short time frame. Change that analog display to a digital one. Reconfigure your site layout to remove confusing features so the user can focus on what is really important to them. Put together a list of the things consumers most dislike or would most wish to see included in your product, prioritize them into a list and determine a strategy to make those things happen.

Last, what about a resource constraint? What if your company's huge project is pulling in all resources while other products of lesser importance fall by the wayside. What do you do when what you are responsible for is having all its resources pulled into a big resource black hole?

You can look for other resources, but you're not likely to find them as the company has already realized its not going to have the money for the big project, much less your small one. You know you've got customers using your small product daily, but they're not getting the support your sales team promised them.

It can be painful, but sometimes your best option is to simply embrace the constraint. Maybe the more time you give to the big project, the faster it reaches completion and the sooner it is your resources come back to working on your project. There are times when all you can do is give in to the constraint.

So what constraints are you dealing with in your organization? How are you dealing with them? Let us know down in the comments!

Introduction to User Stories

2011-11-17T22:01:00.001+11:00

Folks I am running my online Intro to User Stories course again. Sign up via the training page on this site.

Once again the course is free. I have taken on feedback from the last group and spread the content out over 5 weeks rather than force people through heaps of stuff in 5 days. I hope it's a little more of a relaxed pace.

If you are interested in what I consider a really good explanation of the techniques and a discussion about the principles and surrounding issues (e.g. "What sort of documentation do we create?) you might like to sign on.

And of course, you should probably refer a colleague.

My love/hate relationship with 'Being Busy'

2011-11-14T09:00:00.000+11:00

To say that my job has been chaotic over the last 3 months would be a mild understatement at best. I think the late, great Douglas Adams can best sum up the last few months for me:

I love deadlines. I like the whooshing sound they make as they fly by.

Back about 3 months ago, I went into a meeting with my department's VP, expecting to walk out with 1/3 fewer team members and 1/3 less responsibility. I was overloaded as it was and had been told my job needed additional focus on a single, strategic project. What really happened was I walked out with 33% more team members, 50% more responsibility and an entirely new reporting structure. Needless to say, I was a bit surprised, but pleasantly so.

This role has been a lot of fun and includes a lot of additional challenges, all of which are in the direction I want to be taking. Its kind of funny that the things in my job I least enjoy (although I do enjoy all parts of my job, its just that I enjoy some parts more than others) are the ones that are most related to my old role. Nothing bad there at all; I just really enjoy the new stuff I'm getting to do.

But along with all those additional challenges come the realization that I can't do it all; that I can't be everywhere at once. Not that I could before, but the realization is just more obvious now than before. I'll be the first to admit that I'm stressed out, often frazzled and in major need of additional sleep. My mind is racing all the time and my focus is fractured more than a glass vase dropped from the Eiffel Tower.

Which is why this blog post, about the effects of being 'busy' rang so true to me. There were a few lessons that popped out at me from reading this:

First, if you're going to be the best at what you do, be prepared for a LOT of repetitive work. That doesn't necessarily mean filling out forms or shuffling paper, it means spending the majority of your productive time being productive, not just going through the motions. This is hard; it requires drive, determination and all kinds of overused and poorly understood buzz words.

Second, you've got to focus on that work. This is the part of the article where I realized that my analysis skills were atrophying from lack of use. I've spent the last few months in meetings 75%+ of my days. That's not necessarily a bad thing, but it does mean I have less time to spend in focused practice on my actual role.

Yes, much of what is accomplished in those meetings is also part of my new role. One of the things that I enjoy about my organization, especially compared to some really dysfunctional former employers, is that we actually seem to accomplish things in meetings. Wasting every hour of the day in useless meetings really stinks, so I know I'm fortunate to not spend the majority of my time that way now.

Which is where I come to the next lesson of this article: attitude. There have been times, especially during those meetings I feel are rolling around in circles, where nothing really gets accomplished, that I just want to storm out and 'go get some real work done'. This rolls over into my non-work life as well. My evenings have been filled up with processing email that wasn't even looked at during the week. I'm a firm adherent to the Inbox Zero philosophy, so a box with dozens of unread emails makes me twitch like crazy. Its something I just can't help but comb through, no matter how much I would rather be reading a good book (or writing on this blog).

And this brings me to the last point, one not brought up by the authors of the study, namely that being great requires sacrifice. If the 'average' players in the study practiced their instrument 2 hours per day and the 'elite' players spent 6 hours in study, that's 4 hours the 'elites' could have spent elsewhere, but chose not to do so. Being great, or at least doing great work, means not doing non-great things.

I think it is this last point that is what is the hardest thing for me personally about my job. I am thankful that I get to spend my time doing a lot of good things; I just wish I got to spend more of my time doing great things.

So that, in a very wordy nutshell, is exactly why I haven't been spending time on this blog in a couple months. I've missed you all, Better Projects readers. I've missed discussing topics near and dear to the hearts of those of us who do projects. In short, I missed trying to work out how to be great with you all. Lets not be apart so long ever again. I won't promise not to stray for short times, but I do promise to always return.

ISEB on Wikipedia

2011-11-11T23:58:00.001+11:00

From time to time I see new or aspiring business and systems analysts asking the forums whether they should go get certification. Until the IIBA brought out their competing material the most frequent response was to take a look at the ISEB certification in Business Analysis.

I bring this up because I went to the Wikipedia Business Analysts article again today resolved to have a go at making it better. I usually fail in my attempts because there are so many issues with the page as it is today. Anyway, rather than bite off too much I took a look at BA certifications and well, one thing led to another and I have drafted an article in ISEB to replace the previous poorly formed entry.

My proposed (and lean) article is below. If you have an opinion, I'd like to see your comment below, but even better - head over to Wikipedia yourself and help improve the page.

What is ISEB
ISEB is a part of the British Computer Society (BCS). It is a certification body that accredits people to BCS standards within a range of business and information technology specialisations. ISEB is a acronym for Information Systems Examination Board.

History
ISEB started shortly after the creation of the BCS in 1957 to act as a certification body. The purpose of the certification body was to provide a standards group within the industry in the UK.

Framework
ISEB provides a three tiered certification model from Foundation, through Practitioner level and on to Advanced level.

Subject areas
Certifications are mainly built around Information technology competencies, however within the framework there are also several more generalist management certifications.

Licensing
ISEB licences the ability to delivery courses that prepare for certification.

Other services
ISEB also publishes books, papers and holds events and conferences.

International Presence
ISEB is based in the United Kingdom but claims a presence in over 200 countries, mainly through certified people and training organisations.

Related topics

BCS,
Certification,
Information Systems

Sources for my history notes

How to organise a Children's party

2011-11-06T16:29:00.003+11:00

In 2009 I first heard this story. It's still a great introduction to how complex problems don't always need complex solutions.

I'm also looking forward to hearing David speak on Wednesday night this week when he comes to Melbourne, and of course to persuading him to come for a beer afterwards.

#Lean case studies... Stand on the shoulders of giants

2011-10-30T10:52:00.000+11:00

Here is six case studies presented so you can learn lessons from others. two sets of three cases.

Part 1

Build It and They Will Come - David Joyce
Scheduling work in Kanban - Sami Honkonen
Pitfalls of a large kanban implementation - Jasper Sonnevelt

Case Studies from AGILEMinds on Vimeo.

Part 2

Kanban at Cisco - Ken Power
Transitioning from Traditional to Agile in a Small ISV Setting - Mahesh Singh - Sudipta Lahiri
Ericsson Finland Agile and Lean Transformation, Experiences and Learnings - Henri Kivioja

Case Studies from AGILEMinds on Vimeo.

David Anderson considering what #Kanban is appropriate

2011-10-29T22:42:00.000+11:00

David Anderson - Kanban - when is it not appropriate? from AGILEMinds on Vimeo.

Jim Benson on Why #Kanban works

2011-10-29T10:36:00.000+11:00

I think this was my favourite session for the series. The win for me is in seeing a simple message (aka meme) about why this stuff works. What do you think?

Jim Benson - The Psychology of Kanban from AGILEMinds on Vimeo.

John Seddon shares his thoughts on #SystemsThinking in the #lean and #kanban world

2011-10-28T22:23:00.000+11:00

We all know who John Seddon is. What is interesting is hearing these ideas in the context of some of the other presenters such as Karl Scotland, Don Reinerstein and Dave Snowden. Hear what he had to say.

John Seddon - It’s the system stupid! from AGILEMinds on Vimeo.