http://ba-den.com/Ghost 0.5Sun, 15 Sep 2019 08:28:53 GMT60A few years ago I found an app called Todoist. Before that, I was trying to organise my life using plain old pen and paper. It wasn't working. So I did what any (geek?) would do, and turned to software!

I've tried many, many ToDo apps, across all the major platforms (Windows, Android, yes even iOS), but I always return to Todoist. It supports virtually every platform you can think of...

And the guys at Todoist are always on hand to solve any issues or questions you may have. They were also one of the early apps to embrace Material Design on Android, something that gained them an "Editors Choice Award" in the Google Play Store (no mean feat, around only 60 apps of the 1.6 million available have been awarded such an honour). And did I mention they also support Android Wear? Like I said, I'm a big fan of their work! :P

But I digress, you're here reading this article to learn how Todoist (or even simply GTD or todo software) can help you, as it has me. In the following paragraphs I'll explain how I use Todoist to support me in my working life, and how it helps me get more things done quicker. Some of these principles could be applied to other apps, but for obvious reasons I'll be using Todoist to describe them. And honestly, I'm not sure why you would bother using any other app, the number 2 app in this category for me, Wunderlist, doesn't even come close, and that's without even mentioning the Microsoft acquisition!

Core Features

My use of Todoist makes use of all four of Todists central concepts; Tasks, Projects, Labels and Filters.

Tasks are single items consisting of a string of text at a minimum, but may also contain labels, a project, a due date, a priority, comments, reminders as well as subtasks. A task may also contain multiple other sub-tasks.

Projects are logical groupings of task, that can contain both sub-groups (up to 4 levels) as well as tasks.

Labels are additional "tags" that can be used to provide some metadata to a task (think of twitter hashtags).

Filters are ways of filtering tasks based on a set of pre-defined attributes.

Projects

I use Projects to group my tasks into relevant groups. My general rule of thumb for creating a project is:

It has a lifespan of hours/days, as opposed to minutes.

The "project" may or may not have a clear end.

It is an event that has some work associated with it.

These Projects (or "groupings") allow me to quickly see all tasks related to that particular piece of work or objective. I don't tend to use the Projects view of Todoist much, as most of my tasks are built in such a way that I always know what I need to be working on in the near future. However the task views inside the app show the project next to each and every task which helps add some context to individual tasks.

Labels

Labels are where Todoist shines. They really drive my use of Todoist and help me make sense of all the activities I need to complete. My use of labels revolves around the following concepts:

Current task(s) I am working on

Energy required to complete

If the task is for someone else

How long it will take me to complete

Now/Next/Pinned

@Now

I attach the label @Now to the task that I am currently working on. At any point in time, only one task should ever have this tag (and conversely, all completed tasks should have this tag when I hit the done button). This allows me to stay focused on the task at hand, and not get drawn into doing other small things that delay me completing that particular piece of work.

If something else more important does pop up, the label is removed and the new task is promoted to the @Now label.

@Next

I use @Next to contain a smaller set of tasks (one or two max) that I want to work on after completing the @Now task. Again the aim of this is to achieve some level of focus and understanding about my work stack.

@Pinned

Tasks with the Pinned label aren't really tasks at all. I use this label to store small chunks of information about work that I don't want to forget. I try to use this label as little as possible, on the basis that everything I want to do should be expressed as an action (as a task).

@Energy-Low / @Energy-High

I can't remember where I picked up the Energy concept, but it's a label that every task I create is given. It refers to the amount of "life-force" it will take me to complete the task. You can think about it in this way, things I enjoy doing take little energy from me, whilst things I do not enjoy doing take a lot more energy to complete.

This helps me get through more tasks as I can tailor my work against my mood. Monday morning when I'm fully refreshed from the weekend? Ripe time for @Energy-High tasks!

NB. Todoist contains an auto-fill feature when you type the @ symbol. This displays all your created labels. So when I type "@E", it lets me quickly select one of the two labels to reduce the number of keypresses.

@.x.mins

Key to my task structure is an understanding of how long I expect a particular task to complete. I use the following breakdowns:

@.5.mins

@.15.mins

@.30.mins

@.60.mins

@.90.mins

Ideally the 90 and 60 minute labels should be empty. If you're familiar with User Stories, I'd say these tasks are like "Epics" existing on my backlog, and really should be broken down into smaller tasks before I attempt to work on them. Broken down, or potentially expanded into a "Project".

I use these labels and look at the time I currently have free. For example if I have a meeting in 10 minutes I'll look to pick one or two 5-minute tasks to quickly close off. Whereas before this sort of organisation, those 10 minutes may have been completely lost as I attempted to look into a 60 minute task (which would have gotten nowhere in that short time).

N.B. I use the label nomenclature to quickly let me select a time label in a task by only typing "@." then selecting from the list of times.

@Waiting-For

Sometimes, I cannot begin a task until someone else has done something, or provided me with some key information. This is blocking me progressing with another task so accounting for it is useful. I only attach two labels to these tasks, the @Waiting-For label and a @p.fname.lname label.

This lets me know that the task isn't dependent on anything I can do, as well as who I am waiting for (very interesting viewing when the tasks build up for a particular person!).

Filters

Filters are the gem of Todoist. I use filters to drive my task list in a few different ways. The list of filters I use is loosley based on the labels I describe above, here are the main ones:

1. Daily Driver

This is the default screen I see when I open the Todoist app. It show me my immediate tasks and the order in which I should perform them, as well as the tasks I am waiting for others to complete. It's a catch-all, and as the name suggests drives my daily work.

2. Overdue

Query: overdue

This lists purely those tasks with an end date that has passed. If' I am organising myself properly, this filter should always remain empty.

3. Waiting For

Query: @Waiting-For

This shows me a quick view of all the items I am waiting for other people to complete. Along with the created date of the task, I can see how long I have been waiting, and that may prompt me to chase the action point up.

4. Less Than x Mins

Query: (@Energy-Low and @.x.mins), (@Energy-High and @.x.mins), (!@Energy-High and !@Energy-Low) and @.x.mins

I have 5 filters here, each one mapped to a specific time related label. The query groups all tasks within a specific time against the Energy label. This essentially allows me to pick a task based on both its time and energy-draining level.

5 . Draining

Query: @Energy-High

A list of all activities that will drain my energy. If this list has many items, then I should look into why I am not actively looking to complete the "harder" tasks. Some of the additional meta-data against each task could help to provide the answer.

For example, if many of the tasks are related to the same project, why is that project so draining? This can help me tackle any such issues with projects or pieces of work.

6. Fuelling

Query: @Energy-Low

Tasks that give me energy! I enjoy completing these tasks, they re-energise me and help me tackle the more draining tasks sooner. In a perfect world all my tasks should have this label :)

Miscellaneous

There are some other neat features of Todoist that I use actively as well. Recurring tasks, reminders and templates to name a few. I'll give a little bit of insight into how I make use of these features below:

Recurring Tasks

These are tasks that recur over some period, be that days, weeks, months or years. I make use of this feature in a few ways. I have a recurring daily task scheduled for 9am entitled "Arrange Tasks for Day". This is an important part of my workflow and sets my list of work items up for the day so I can focus on doing instead spending time during the day figuring out what to do.

Templates

Templates are a great feature of Todoist that allow you to create a Project structure, and then export it as a saved template. You can then import than template as and when you need to. I use it for specific tasks that have a set list of actionable items. For example one template I use is for when a new starter joins my team. There are a number of tasks that must be completed such as building tours, building passes, desk reservation etc.

New Task Workflow

I hope the above doesn't make it sound too complex, because it isn't. When I have a new task to do, this is what I do:

Click the shortcut key programmed into my mouse to add a new todoist task.

Type the task description.

Type @. and select a time.

Type @E and select an energy level

Select the day I expect to complete it.

And that's it. The rest is all managed through the predefined filters.

I hope that the insight into what works well for me will give you some inspiration in creating a structure that works well for you. Feel free to try and replicate my process, or take some bits and integrate them into your own ways of working.

If you have your own way of doing things, let us know in the comments!

If you're involved in the requirements trade, you might have heard something similar when gathering the requirements for your project.

Another example I overheard recently was:

"My car is broken, this is terrible, I absolutely need it to get to work"

What do both of the above have in common? Both use the word need incorrectly. Do I really need my smartphone to survive? Would I die if I didn't have a smartphone..? Maybe Probably not!

Did the person above really need their car to get to work? Again, probably not. It might have made the journey to work a lot easier than having to walk to the bus stop, but that is still a want, not a need. Their actual need is the ability to get to work somehow.

What's The Connection?

So what does any of this have to do with requirements? A key role of the Business Analyst (or that person wearing a BA hat) is to understand the difference between a need and a want.

Needs are those things that stop a required task from being able to occur. There is no other way to get that job done.

Wants are those things that can be skipped (even if just for the initial development cycle), and do not impact the ability to complete a goal or task. The workaround may be tough and time-consuming, but it is a workaround nonetheless.

Disguising wants as needs doesnâ€™t help anyone. Developers may struggle to include all the â€œneedsâ€ into a single development cycle pushing out the release of a usable product unnecessarily. No product means no users, no revenue, no profit.

The benefit of correctly identifying and delivering on the needs not only allows a useable product to be delivered sooner, but allows us to learn from the real-life usage of the system. And maybe learn that those original â€œwantsâ€ (that were actually needs) arenâ€™t even wanted anymore!

]]>http://ba-den.com/yes-i-need-my-smartphone/e278921c-5902-4865-a6d2-8c79de6915e2Fri, 29 May 2015 15:20:28 GMTUser stories are a fantastic tool, we can all agree on that. But it's far too easy to write user stories that are too large. Large stories bring a number of problems, including:

The development effort required to deliver a story is hidden.

They are written at a higher level, and therefore are more vague.

Multiple features are encapsulated into a single story.

They don't demonstrate the value of smaller functions.

Acceptance critera becomes a way of including more functionality, rather than as a tool to prove the story was delivered correctly.

However, fear not! There are many methods we can use to attempt to split a user story up into multiple (and more valuable) smaller stories.

Vague Story

As a user, I want to amend my order, so that I can inform you of any changes I want to make before you deliver my order.

The above story is quite vague. What exactly does amend mean? The customer may be able to amend multiple different aspects of their order. Some of these may be more important than others.

As a user, I want to amend the CRD date of my order, so that I can request for my circuit to be delivered at a later date.

As a user, I want to be able to amend the site contact for my order, so that you have the most up to date contact details for any site visits.

We now have two stories, which we can both prioritise and explain the value of separately. But not only that, we are also giving the delivery team greater flexibility to deliver one or both of the stories depending on their ability to deliver within a single sprint/development cycle.

Complex Story

As a customer, I want to order FTTP, so that I can get high-speed internet access.

The order journey is extremely complex, there is little chance of delivering it all in one story, However, we can attempt to split this story up by the separate aspects of the workflow. What does the user have to do in order to place an order?

As a customer, I want to choose an FTTP usage limit, so that I can pay for a product in line with my usage

As a customer, I want to check if I can order FTTP using my CLI, so I don't go through the order process if I cannot get FTTP.

As a customer, I want to check if I can order FTTP using my postcode, so that I can check if a premise can access FTTP before I occupy it.

As a customer, I want to pay by direct debit, so I donâ€™t have to worry about remembering to pay you every month

As a customer, I want to pay by debit card, so I can manage payments myself.

Those are just a few of the stories from the user perspective, as you can see we are splitting the large story up into its component pieces, that can each be delivered separately. Not only that, but we may choose to delay some of the less important stories to a later phase too, as they may not form our view of a minimum viable product.

Conjunctions

It's really easy to use conjunctions in a user story, but we should try to stay away from it. Words like "or", "and, or "it" mean we are clumping multiple features into the same story.

As a customer, I want to pay by credit card or PayPal, so that I can purchase an item.

For most of the reasons mentioned above, we should definitely split this story up into its independent functions.

As a customer, I want to pay by credit card, so that I can purchase an item.

As a customer, I want to pay by PayPal, so that I can purchase an item without giving you my card details.

Subjective

Subjective words are a developers worst nightmare. Works like "easily" and "quickly" all mean different things to different people, and the chances the stakeholder and the developer have the same perspective is very small.

As a customer, I want to place an order quickly, so that I donâ€™t have to spend a lot of time on your website.

The above story can mean many different things, so it's better to be explicit.

As a customer, I want to skip the registration process when placing an order, so that there are less steps I have to go through before submitting.

As a customer, I want you to populate my address after providing my postcode, so that I donâ€™t have to enter my address manually.

The above stories make clear exactly what the requirement is, the developer doesn't have to guess what the user really wants.

Acceptance Criteria

One of the issues with large user stories is that we revert to encapsulating requirements into the acceptance criteria of a story. This isn't good for anyone.

As a user, I want to receive updates to my order, so that I know how my order is progressing.

AC1: Does the user receive an email when the order is accepted?
AC2: Does the user receive an email when the the planning phase is complete?

Again, lets split up this story with encapsulated features into the component parts.

As a user,I want to be informed when my order is accepted, so that I my order is being worked on.

As a user, I want to know when the planning phase of my order has been completed, so that I can prepare for the survey.

By splitting this type of story up, we make the story smaller and more manageable. We also get the ability to give each story a separate priority.

For example, it may be the case that it's important for a customer to know when their order is accepted, but less important for them to know the order has passed planning stage. As such the second story can be delivered later, perhaps in a separate release, instead of having to delay both features if they were within one story.

Benefits

We've mentioned the benefits of splitting above, but here's a quick recap:

They help us to understand the users and their usage better.

Stories have a better chance of fitting into a single release.

Acceptance criteria proves the want, rather than being wants in their own right.

A greater breadth of requirements are captured, resulting in less vague statements.

They are easier to estimate, the story doesn't include any hidden functionality.

The business has a better understanding of the value of the story.

Here's a visual example of point 2:

As ever, the concept of user stories unfortunately isn't black and white, so let me know what you think of the above techniques, and if you have any others to add?

]]>http://ba-den.com/why-should-we-split-up-large-user-stories/3aac63e2-2f37-4c3a-ae73-da8659fb0137Fri, 13 Mar 2015 15:39:35 GMTAs a Business Analyst, one of the key features of a requirement is the priority.

I guess it's important to state up front that all requirements are important. If they weren't, we wouldn't even bother documenting them, thus removing the need to even assign a priority. But having a priority is useful to help deliver the most valuable features first.

An example to illustrate this point could be a search feature. A high priority feature might be to provide the ability for a user to search for an item:

As an end user,
I want to search for an item,
So that I can quickly find the item I am looking for

A lower priority item could be the ability to filter the resulting search items:

As an end user,
I want to filter the list of returned items,
So that I can narrow down the scope of the returned list to help me find an item faster

If we assume that being able to search is a key feature of the system, we would assign a higher priority to that feature, so the development team can understand what work to place before others.

How?

One of the more popular ways to specify a priority (and the one I personally recommend) is using the MoSCoW method. The o's are really just there to make it into a word we can reasonably say. The four upper case characters essentially define the 4 levels of priority we can assign to a requirement:

Must have

Should have

Could have

Want to have (or Won't have, depending on who you ask..)

What we usually find however, is that people don't really understand the true meaning of MoSCoW. This invariably leads to most, if not all of the requirements being labelled as "must have".

Must have

Must have requirements are essential to the success of the project. If any "must have" requirement isn't met, then the project is deemed a failure.

Another way to approach a must have is to ask the question:

if we can't deliver this story, should we cancel the project?

If the answer is yes, then it's a must have requirement. If the answer is no... then maybe it might be better represented as a should have.

It might be useful to think of the word "Must" as an acronym for "Minimal Usable SubseT" before you make all of the user stories in a demand must have priorities. Think about what the solution really needs to implement in order for it to add value to the user. Those should be your "must have's". Ideally must have requirements will form the majority of the requirements for any particular demand.

Should have

Should have requirements are important to the success of a project, almost equally as important as a must have. The difference being that the end solution should still be delivered if for any reason an S requirement couldn't be delivered.

I think the lack of "should have" requirements stems from a lack of trust between those with the want, and those delivering the want. Product Owners may assume that their should's won't be delivered, and so force everything through as a must have requirement in order to guarantee everything that they want gets delivered.

I think this view is wrong, the true definition of a should have requirement is something that is still essential to a solution, but that the solution still works without them. The development team should also understand what a product owner means when they say a requirement is a should have, if not how can we expect to receive requirements with anything other than a "must have" priority?

Could have

Could haves are again a drop down in priority. Where we would view meeting all must haves and should haves as a project success, the delivery of could haves are the "icing on the cake". They usually add value to the user, as opposed to having a negative impact if left out.

Want to have (or Won't have)

Requirements with this level of priority are effectively deemed out of scope for the current phase of development. They could however, be important requirements for a later phase of development. At that time, the requirement should be re-scoped as per the priority for that phase.

It is useful to define these requirements to effectively scope the boundary of the project, as well as to ensure future requirements are documented.

Tips

Ensure all interested parties understand what each priority means (Warning - this may require a shift in mindset).

Make all requirements "Want to Have". Increase the priority when you can justify doing so.

Ask the question "If we don't deliver this Must Have, should we cancel the project?".

Is there a manual work around? If so, it may not be a "Must Have".

Conclusion

If your demand consists of 10 user stories, each of which is classified as a "Must Have" requirement, consider the usefulness of prioritising them at all.

MoSCoW gives us a great way to define priorities, using natural language we can all relate to. Let's use it as it was intended, to deliver great products!

]]>http://ba-den.com/but-i-want-everything/c8ae6210-4051-4d51-b219-64253216cbebFri, 20 Feb 2015 11:05:43 GMTOne of the key traits of a Business Analyst is being able to separate the "What" from the "Why".

Users of the system (and remember, stakeholder != user) generally have a pretty good idea of what they want to do, but sometimes their explanation doesn't tell the whole story. The line between the what and the why is very blurry.
Let's take an example to illustrate. Suppose we have a system that contains a list of items. Typically, we'd get a requirement to allow the user to sort this list, in the form of a user story it might look like:

As a user,
I want to sort the list

Fine. But as a Business Analyst it's our job to understand the why. Why do you want to sort this list? For enjoyment? Probably not, it sounds like there is an underlying want here. This "requirement" is what I like to sometimes call...

"A solution masked as a requirement"

Digging deeper (maybe using the 5 Why's technique?), we can get close to what the user is actually trying to achieve. Let's document this in story form too:

As a user,
I want to view the top 5 items in the list by most sales

There we go! By further probing we can see that the users goal wasn't actually to sort the list, it was to find the top 5 selling items. The sorting of the list was just the users initial assumption as to how they could see the top 5 items.

Looking at the user story, it's important to understand what benefit the user will get from finding the top 5 items too. This will help us prioritise the requirement and ensure developing the feature will actually be beneficial. Again, let's use a user story to describe this:

As a user,
I want to view the top 5 items in the list by most sales, So that I can promote these more in our next marketing campaign.

Ok, we understand what the user want's to do now, and what benefit they'll get from that feature being delivered. This understanding allows us to create a solution more aligned to meeting the real goal of the user.

For example, instead of just adding a sort to the list (which itself is vague, e.g. sorting by all columns? Just one? In what order?), we might display the top 5 selling items in a separate chart, or provide further information on them, as they seem to be of most interest. Maybe we could add a simple way to send the top 5 items to the Marketing department? Maybe the Marketing department should have direct access to the top 5 items?

Understanding the real desire helps us provide a more valuable solution, meeting that true underlying need of the user, and hopefully providing a solution that goes above their expectations!

One the one hand, you have a nice easy path to the final app. Your app works on all of the major mobile platforms (let's just say android and iOS for arguments sake), you have one (or at least, close to one) codebase to maintain, and it probably hooks into each of the native APIs quite well too.

But... The app probably won't win any design awards. It'll probably have a broken experience (relatively speaking) compared to the native apps available on that platform too. Users may not quite understand how to interact with it, because it doesn't quite meet the interaction standards that the specific platform proposes. Sure, you can force it to act like it does (maybe by mapping the android back button to a specific action), but overall the app probably just won't "feel right".

Then you have the native route. Your app will look fantastic, it'll work across all the different devices available on a specific platform as it should (because you followed the specific development guidelines, you did right? Right...? o_O). Users won't even have to read your FAQ or send you an email, because the app works just like all the other great native apps they're used to using on their device. You might even get mentioned on a Tumblr blog.

It's a difficult choice to make. One invariably costs (and not just monetary cost) more than the other, and will probably take a bit longer to get there too. But the end result will should be a lot better. The type of audience an app is targeted at should be included in the decision, not very tech-savvy? Maybe you might just get away with a non-native app... As long as you're happy to handle the grumblings of a few purists (um... not mentioning any names...!).

]]>http://ba-den.com/the-app-dilemma/4b8fb9f3-9add-403d-8a8c-d663c1f7f63aWed, 11 Feb 2015 15:52:09 GMTUser stories are a great way to manage requirements, they are small, light, to the point and make the benefit of any requirement explicit.

However, just like traditional requirements, there is a skill required to 'get them right'.

Below is a quick hash up of some user story mistakes.

1. The Acceptance Criteria

The acceptance criteria is a key aspect of any user story. They provide a reassurance that whatever gets delivered is what was originally intended. Some of the more common mistakes are:

Acceptance criteria that doesn't actually prove that the 'want' has been delivered.

Too complex

Each should answer "yes or no", not "yes and no").

Too low level (remember this is the 'what', not the 'how').

Think about the output, as opposed to how the tester will get to that output.

Too much detail

e.g. better to say "does the page allow the user to enter their address details as per the address capture business rules".

than to have a separate rule for "can the user enter their town"/"can the user enter their postcode"/etc

2. The User

It's all to common to see the user of a user story being labelled as "user". This is way too generic, and points to the writer lacking an understanding of who will actually gain benefit from the story. If we can't identify who the user is, are we even sure the change will benefit anyone?

Sometimes the change may benefit a group of users, instead of writing the same story for each of them, it may be beneficial to understand the role each type of user is playing when they get the benefit. If this role ends up being the same, say that. Use the role in the user story (but highlight separately who may be performing this role). If the users are not playing the same role, then double check that they are actually getting the same benefit. You might find that in fact a single change helps different users in different ways, and in this scenario it's probably best to highlight this into different user stories.

Another common mistake is having the product owner as a user, but the benefit being given from the perspective of another user. The user having the 'want' should always be the user getting benefit from that 'want'.

It's also quite common to see the user being a developer, for example a change being required that doesn't seem to deliver user benefit, but may be required to reduce technical debt, etc. I'd argue that this type of change shouldn't be represented as a user story (is this really the what? Or is it the how?). If we really think about why the technical change is required, there may actually be end user benefit, for example it may result in a certain aspect of the system running faster, or allowing more concurrent actions etc.

3. The Want

The goal of a story is to define the 'want'. It's a single, small feature that a specific user wants in order to give them some type of benefit. Some of the pitfalls are:

Too ambiguous.

If the want is ambiguous, then what gets delivered turns into a lottery. The business user expects one thing, the developer delivers something else, while the tester tests for something entirely different.

Too complex.

The want should be a single piece of functionality. Using words like 'and' adds unneeded complexity to a user story that make meeting that story more difficult.
There is little reason why you shouldn't split a complex story into multiple smaller stories.

Too technical.

A common issue for all type of requirement. Requirements are the 'what', not the 'how'.

The user story defines what the software should do, how the software actually does that is the domain of the designer/developer. The business or end user has little interest in the latter.

Any comments on the above? User stories (like much in the BA world) are not black and white, there are always exceptions to the rule, the key is making sure they stay exceptions, and not end up being BAU.

]]>http://ba-den.com/3-common-user-story-mistakes/aec2c4fa-53f8-4191-8e0b-318b1e618dd9Wed, 11 Feb 2015 15:50:13 GMTOne of the simplest techniques known to a BA can, in some cases, be the most effective. We call this technique, "The 5 Why's".

What Is It

The 5 Whys technique is a form of root cause analysis, which originated within Toyota, and is now a fundamental part of many methodologies including Kaizen and Six Sigma. The technique boils down to asking the question "Why?" 5 times in order to determine what the real issue is (I'm sure you remember The Simpsons episode? :P).

Just like a child who wants to immediately know why you gave the answer you did, we as a BA can ask the same question (5 times should suffice) until we understand the real cause of a problem, as opposed to simply a symptom. From here we can take steps in order to fix that problem.

How Do I Use It?

It sounds simple, and it is!

It begins with a statement of the problem. Writing this down ensures everyone is on the same page, and has a full understanding of the issue at hand.

Next, ask why this issue occurs.

Does the answer to the Why? question look like a root cause? (Is there another answer to the Why?).

If not, ask Why? again. If it does, you've found the underlying issue!

As mentioned, it usually takes 5 iterations of the above steps 2-4 to find the underlying cause. It may take less, or it may take slightly more depending on the complexity.

Example

Problem: I can't get all my work done to meet my deadline.

Why (can't you complete your work in time)?
Because my computer keeps freezing

Why (does your computer keep freezing)?
Because the specs are too low

Why (are the specs too low)?
Because IT won't give me a new laptop

Why (can't you get a new laptop)?
Because they don't have enough new laptops to hand out

Why?
Because new IT equipment is a low business priority

We could have stopped at any of the above points. But we would never have found the underlying issue. We could have given the (let's call him a BA) a new laptop, but that wouldn't fix the issue for everyone else who may be having the same issue. Once we know the root cause we can take steps to fix it.

Why Should I Use It?

Using the 5 Why's help us to identify the real issue, the underlying cause It stops us from just simply providing a "quick-fix" to the main issue. Fixing the real cause is usually a lot cheaper in the long-term.

Tips

Try not to fall for generic statements, or end-reasons that are out of our control, such as "not enough time" or "human error".

The underlying cause is usually a process issue.

Focus on the process, not the people. If a person is making a mistake, the process that allows them to make that mistake should be blamed, not the person (or team) themselves.

There may be more than one underlying problem, but try to stick full to one path before switching to another.

Be objective. Remove any pre-conceived ideas of the issue as this may alter your judgement.

Feel free to ask any questions on the above (as long as they are not "Why?"!) ;)

]]>http://ba-den.com/the-5-whys-technique/8bb2cc9d-0679-4809-ad68-443bee966ce8Wed, 11 Feb 2015 15:44:22 GMTI read an interesting article recently, that used a restaurant scenario to highlight why the customer shouldn't see the inner workings of how food is created in the kitchen, and a lot of this rings true in the world of the BA too.

The Roles

Let's explain the roles in the restaurant scenario first. We have:

Customer

The customer in the restaurant ordering food is like the stakeholders of a software project. They have a set of requirements (what they want to eat), which is eventually built for them and returned for their consumption.

Chef

The chef is the development team (you might even say the head chef could be â€‹the system designer). They build the meal to the customersâ€‹ expectationsâ€‹.

Waiter

The waiter can be see as the Business Analyst in this scenario. They speak to the customer (stakeholder) in order to find out what they want to eat and drink. Sometimes they might push a certain agenda to the customer (if perhaps one of the meal options contains an expensive ingredient, or simply because a lack of a certain ingredient means making one of the meals cannot be done, or worse, substituted with a different ingredient!).

The waiter also interfaces with the chef, informing them exactly what the customer wants, including anything specific that isn't part of the original meal, or even perhaps a customisation (medium-rare steak please!

The Scenario

So lets try and use the above scenario to explain some best practice.

The customer is really only interested in the meal that will be placed in front of them. They care that the meat has been cooked medium-rare, that there is a side of peas on the plate, that the steak sauce is sufficiently spicy enough for their tastebuds, that a steak knife has been provided.

They do not care about how that piece of meat has been cooked. They have no interest in the type of frying pan used, or what position on the hob the pan was placed on. They don't even really care about what specific ingredients have been used to create their wonderful steak sauce.

Could you imagine walking into a restaurant to order a steak, and the waiter walking over and asking you to confirm the pan to be used to cook your meal? Or to decide which herbs to put into your sauce?

Issues

There are three main issues with the above.

Firstly, the customer doesn't care about those little details, bringing them into the conversation means more time spent over the how, and less time spent over the what. They'll end up picking the pan to cook the steak in, but you'll end up serving them a chicken as the requirements have been lost in the detail, or potentially not even discussed!

Secondly, the customer is probably not even the right person to be deciding on the pan to be used. That's the Chef's job. The Chef understands the world of pans a lot more than the customer, they are in the best position to be making this decision.

And thirdly, what if all the pans the customer had chosen are old and battered, and not up for cooking steak any more? If the customer chose the pan, the Chef has to inform the waiter this cannot be done, the waiter has to then go back to the customer and tell them to pick a different pan.

If the customer lets the Chef choose the pan, then the Chef is free to pick the best pan out of those available to do the job. No need to hold up the process to ask the customer to raise a "change" with the waiter. The customer then gets their food quicker, and maybe even to a better quality as the SME (the Chef) has already picked the best approach.

Conclusion

I see this a lot, and it's one of the biggest reasons as to why requirements are not met, and sometimes not even gathered.

A project's success is defined by how well it meets requirements. So... How can we deem a project a success if we don't even know what the requirements are?