Test Driven Requirements

{Disclaimer – this is a cross-posted article appearing both on the Triton-Tek blog and my personal blog Budding BA}

My job at Triton-Tek is not an easy one to define, but predominantly I am a Business Analyst and Project Manager on Agile web development projects, see my previous articles here and here.  However there is one major project on which I have been working since day one that has required a lot of Quality Assurance (QA) support from me so that the developers get quick feedback on their work.  This work as a QA, has been incredibly beneficial to me as a BA in crafting the requirements for the project.  In an Agile environment, the approach is very much “just-in-time”, and the same applies to requirements gathering.  We will have a set of stories for the release, and a plan for the current iteration, but the specific ins-and-outs of the stories are still very foggy.  So as a BA I will add details to the stories as they come up, but often it is an iterative feedback loop that defines the requirement.

Agile User Story completion cycle

Because of this emphasis on QA in my role I started to read about how to do this in an Agile fashion, and the results are fascinating.  The connection between the QA role and the BA/requirements role in Agile projects is very strong, and the Agile testing techniques I have learnt have helped my requirements analysis and definition as a result.

This mindset change starts with the “Agile Testing” book by Lisa Crispin and Janet Gregory.  It is quite a large book, but very practical and describes in detail the daily hands-on role a tester must play on an Agile project.  I will not review the book here, that is another post on its own, but I am adding the Agile Testing Quadrant below as it gives a good overview of the different areas of testing.

Agile Testing Quadrant from "Agile Testing" by Lisa Crispin & Janet Gregory

Essentially the book drills home the many different angles from which the product must be tested in order that you can be sure of as solid an end result as possible.  Critically the developers must practice Test Driven Design (TDD) for this all to work.  This is accomplished by starting with failing unit tests (because the functionality does not yet exist) and then coding the solution so that the tests now pass.  So for example, they would start with a test titled “User can enter a username and password to login”, and then code the user login functionality so that the test passes.  I learned of TDD upon starting at Triton-Tek and understand what its purpose was, however since reading this book my eyes have been opened to how the same approach can be used when gathering requirements, and how that can feed directly in to the code, simultaneously creating automated unit tests and setting the acceptance criteria for when a story can be considered “done”.

Now, before I continue, I want  to stress that this is not a new discovery on my part, there is a community around Acceptance Test Driven Design and Behavior Driven Design (BDD) that talk about exactly this process.  However, as a BA with no coding background, the personal progression in understanding of how this all ties together is one from which I think a lot of BA’s can benefit.

Going back to the quadrant above, the area we are focused on is Q2, the functional and story tests that can be automated.  The book specifically talks about using the FitNesse tool to automate functional testing.  This tool allows you to create understandable “business” phrases, using a certain format, that the developers can then take and use a fixture to directly test their code to make sure the functionality works as the business expected.  The great thing about this approach is that it expands on the quickly jotted down acceptance criteria on a story card so that the developer is immediately presented with the list of tasks he or she needs to complete in order to call the story done.

From a BA perspective, this approach is hugely helpful.  Since reading about FitNesse, I spoke with the team at Triton-Tek and Matt Hidinger recommended SpecFlow as that uses the more business and domain friendly BDD approach, building on the Cucumber syntax, and integrates easily with TFS and the .NET world in which we work.  In BDD, the tests are created using the following syntax:

Given [condition]

When [action]

Then [result}

So an example would be:

Given the user has already registered

When the user enters the correct username and password on the login screen

Then the user will be logged in to the system

These “Given .. When .. Then” statements can then be used by the developer as the basis for their unit tests ensuring the functionality of the story meets the business / user requirements.  This is a very simple, but powerful tool for a number of reasons critical to a BA’s work:

1. The language is easy to understand, so it can form the basis of supporting requirements documentation.
2. Anyone can write them, so you can pull in stakeholders and product owners to directly contribute.
3. They encourage analytical and practical thinking about the requirement.
4. Reduces the lost in translation problem of transferring business requirements to the developer.

So now with my BA hat on, when I am expanding on the requirements for a User Story, I can start walking through the many business rules, user scenarios and use cases using the “Given .. When .. Then” statements.  This always end up uncovering hidden problems or complexities, that may not have been discovered until development had begun.  It is also a fantastic way to keep the product owner or client representative involved, the statements are easy to understand so any business user can create them, meaning that they are setting their own acceptance criteria.  This is very important in a consulting environment such as ours where any misunderstanding of what functionality a user story should actually achieve can have large monetary and client/contractor relationship ramifications.

Now with my QA hat on, the biggest bonus to this approach is that I have simultaneously created automated functional tests, and encouraged TDD behavior from the developers.  This should allow me to focus on the more fuzzy (and in my opinion, interesting) exploratory and usability testing, which is where I can add the most value to the product and the team.  Overall, everyone wins, and most importantly the requirements are delivered seamlessly from the business to the development team.

Resources on this topic:

• Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin & Janet Gregory
• Lisa Crispin’s blog and follow her on Twitter @lisacrispin
• Brian Marick’s blog – an Agile tester and developer, strongly influenced Lisa Crispin
• Behavior Driven Design (BDD) – the original article by Dan North
• SpecFlow – the .NET BDD tool
• Cucumber – the language behind SpecFlow
• Acceptance Test Driven Development – also see the deck below
• Yahoo Agile Testing Group

When User Stories are not enough

I recently attended an interesting webinar by MKS on why User Stories are sometimes an inadequate representation of requirements.  I thought it raised some excellent points, and certainly got me thinking.

Starting with a refresher on what User Stories were, the presenter Colin Doyle emphasized how they are NOT a requirements document.  Instead they are a placeholder for continued conversation on that particular piece of functionality and used especially for prioritization.  They are the tool through which requirements are communicated and discussed rather than delivered in the form of hefty requirements documents (see this excellent article from Mike Cohn on User Stories).  As Agile prescribes, in teams where face-to-face, daily communication is possible and the Product Owner and key stakeholders are readily available, the User Story format works very well.  Each story follows the INVEST criteria and are first and foremost independent of other stories, and the non-functional requirements or constraints do not dominate.  With each iteration, the product develops incrementally with the gradual evolution and folding back in to the project of the inevitable changes that will arise as the product comes to life.  If there is a need to review the requirements and see the “big picture”, then the User Stories in combination with Test Driven Design (TDD) or Behavior Driven Design (BDD) practices, should provide all the details you need.

Colin Doyle argued the point however that there are 3 key issues with this method, all centered around the scalability:

1. Too many customers for the product resulting in conflicting requirements and a significant effort to understand customer environments and needs.
2. Complex products with significant interdependencies, lots of exisiting requirments and the lack of a way to see the big picture easily.
3. Large organizations where “scaling of face-to-face conversations is an N2 function (Brooks)” and may include offshore or off site teams.

Therefore he recommended the careful introduction of some traditional requirements engineering practices to help solve these issues.  In particular using modeling techniques such as use cases, decision

Use Case Model example

trees or event-response tables to get a handle on the big picture.  This will help the project in number of ways.  Firstly the developers will understand the full scope more clearly and so guide their TDD/BDD test cases and hence their code.  It will also help the Product Owner who may be unable to remain fully informed for large, sprawling products.  These requirements artifacts will also form the basis for a high level dependency analysis from which relatively independent User Stories and backlog items can be derived.  This should ensure that you arrive at a position with nicely traceable project, from the high-level product owner level down to the actual code.  The presenter was not arguing for a bastardization of the Agile philosophy by doing this requirements analysis upfront, he stressed it should be performed in a just-in-time, iterative manner, and the requirements artifacts changed and adjusted as the product develops.

I am receptive this approach.  I don’t think that the Agile community should unconditionally shun traditional requirements engineering practices as “old-school” and no longer relevant.  My concern with the approach is how easy it would be to slip in to a gather requirements up-front process.  The models and artifacts could become weights around the neck of the project requiring constant revision, whilst at the same time being the excuse why something was done a certain way.  I believe that the Agile methodology, with it’s primary emphasis on conversation over documentation, promotes an environment of “ask before you act”, to ensure that the correct path is chosen.  If there is too much documentation available, this can be viewed as the definitive answer, and reduce the amount of communication within the team and clarification with the product owner.

But that is not say I am ruling this out, and in fact I think I will try and incorporate this approach in to the next complex project I work on.  I think that so long as the culture of the team remains inquisitive and conversation intensive, these models can be good aides to discussion, just like user stories.

Mind Maps – A Love Story

It’s a tacky title I know, but what is really tacky is that it’s true. Over the last few months I have used Mind Maps for such a wide variety of situations, that I thought it deserved its own blog post.

I have found Mind Maps to be an extremely versatile visualization technique, helping me capture and clarify information.  Through the presentation of disparate information objects on one screen, connections between those objects present themselves naturally. I have personally found it also promotes creative thinking.  Because the maps removes the notion of a list or paragraph of text, it instead encourages your brain to not only make connections, but also to think ahead, imagining new and different threads growing from the connected or unconnected objects.

Here are some examples of the scenarios when I have used Mind Maps.

Requirements meetings

This is a BA blog so requirements are the most natural place to start. I have used the Mind Map tool to capture notes in a meeting on requirements and have found it to be very effective. By creating a node for each requirement stemming from a central node of a theme or screen, the notes and comments build around the requirements nodes very naturally and you start to quickly see questions and dependencies between requirements.   Using the relationship arrows, references to previous points can be quickly made, and those relationships jump out at you because of the presentation style of your notes. Also little features such as adding Priority and Star icons let you markup your notes effectively so they can be efficiently acted upon later.

Brainstorming

This is the classic application of this tool. The quick way that nodes can be created, manipulated and connected is perfect for a session where you need to come up with a new idea or creatively work your way out of a situation or dead end. There is a throw-away and casual nature to recording information on a Mind Map.  It feels flexible and malleable, and more of a marker for further discussion. Noting down something on a list creates a more static representation of the information, and, to me anyway, constricts my thinking on topic.

Brainstorm

Workflows – States & Transitions

This was a surprising application of the tool, and I cannot take credit for it either. A colleague was trying to get his head around the workflow and accompanying states and transitions for a touch screen Silverlight application our team had developed.  There was a bug and it could not be nailed down and we needed some way of seeing the steps on the UI and the behind the scenes associations to methodically track down the problem.   Using the mind map tool, combining the structure templates provided to arrive at a fluid and effective visual representation of the workflow.  It was a more “folksy” or ad-hoc approach to a formal UML activity diagram in Visio, but was immediately understandable and allowed everyone on the team to contribute to solving the problem, whether they are tech minded or not. Since then I have used the same method for a Site Map that also showed a fields and associations. I plan to write another blog post on the discussion this raised for me about when to use formal diagramming techniques vs. whatever technique transmits the information most effectively to the average person.

States & Transitions

Problem Solving

Finally, I have used mind maps to flesh out ideas or to start solving problems that are rattling around inside my head. One of my idiosyncrasies is that I am a verbal problem solver, by saying something out loud I start to understand the problem better and so more often than not arrive a solution at that very point of verbalizing.  But for those times when talking out loud is not possible, I have used mind maps as a way to quickly right down the key ideas and connect and move them around, and the results have been very similar.  It gets those problems out of my head and allows easy manipulation which often allows the answer to present itself.

So what mind map tool(s) are you using I hear you cry? Well just one has been enough, and the good news is it is free!  Check out XMind (http://www.xmind.net/).

You can also try these options listed in the Wikipedia entry on Mind Map Software.

The Agile BA / PM – First Impressions

So I am 12 weeks in to my new role as an Agile Business Analyst, so I wanted to give a summary of my impressions, and how the role combines with being a Project Manager and QA part-timer.

1) Documentation

No more paperwork!

This is the biggest area of change for me, and from my perspective a welcome relief.  Gone are the bulky Business Requirements Documents that I slaved over for days, only for the customer not to read, and for the team not to look at again once the review is over.  Agile is agile because it is nimble.  You do not weigh yourself down with hefty tomes, documenting every in and out of the project.  Instead, stories, and scenarios are used.  Work is done firmly at the business level.  What does the business need?  Let the Technical Lead do the interpretation.  Yes you need to be grounded in technical reality when the implementation starts,  but you don’t know why you are doing it unless you have captured the business level goal.  This can normally be captured in a sentence, or short story, and the simpler the better.

2)  Requirements Gathering as a Conversation

Requirements are a continuous dialogue.

The convention of Agile requires that the customer be heavily involved in the project throughout the lifetime of development.  Although we cannot incorporate the customer to the level we would like, we are still delivering working functionality and demos every week or two, so a constant stream of feedback is available.  This dramatically changes the requirements gathering process.  Working from iteration to iteration, as the BA I work ahead of the developers as much as possible, reviewing the stories and clarifying requirements.  However more typically I am working in the moment with developers as requirements questions come up, because they don’t know the roadblocks or lack of understanding until they really get in to working on a story.  So on these occasions, we are having ad hoc meetings with the customer, discussing their needs and working through use cases, that will result in working functionality very quickly, typically no longer than 2 weeks.  The discussion therefore remains fresh in their mind, the decision is captured and implemented quickly, and the presentation of the result is fast.  I have found this to be a very effective way to seek requirements and verify their understanding.  Nothing is ever captured and documented, never to mentioned again until weeks or months later when the product is delivered.  This is why requirements gathering now feels like a real dialogue, a never ending conversation stream connecting the developers to the business, and vice-versa, through myself and the Tech Lead.

3) Project Management

Not Project Manager, Project Co-ordinator.

This is the completely new area for me as I have never been a Project Manager before.  However, once again, Agile to the rescue! The PM role in our Agile projects is very limited, and in fact we call it Project Co-ordinator to stay true to the team ethic of Agile.  We are all in it together and not under the instruction and watchful eye of a manager per se.  The small teams, and heavy involvement I have as the BA means that I have my finger on the pulse of the projects progress.  But more importantly, the iteration development cycle means that we are never falling behind schedule or stressing about keeping Microsoft Project up to date.  We assign stories to be completed in an iteration, based on the number of points we estimate can be completed.  One or two weeks later, we know if we have hit that or not, and we estimate the next iteration based on the last.  Apart from that, I do some burn down charts, however not for all projects, it depends on the customer, as does whether they need some thorough updates as we progress, but really the PM responsibility is limited.  Most critically in this role I feel the need to stay Agile.  Don’t get bogged down in facts and figures and work that does not have business and customer value.  It is a powerful motivator to stay on track, and follow only those critical metric required for the project to succeed and to keep the customer happy.

4) QA as Usability Testing

What is the customer experience?

I have found this area to be the most challenging and perhaps, dare I say it, the least interesting part of the process.  It is a vital aspect to the process, no doubt, however my lack of training or formalized approach to this function means that I maybe create more work and more repetitive actions as I feel my way through the process.  However, I have found it is an excellent opportunity to do some rudimentary usability testing.  I put on my “I am the user or customer” hat and dig in to the fledgling software, asking the basic or simple questions of the developers to see if there is a better or simpler way to do things.  So it is not just Use Cases, bugs, issues, report, it is once again a more fluid dialogue of not only the issues found but maybe a better way to organize a screen or function during the next iteration.

Overall, I am thrilled with my new role. I am learning so much, and I am involved in so many things that I have wanted to be doing for so long now.  I will try and keep the articles coming as I truly define my place as a Business Analyst / Project Manager in the Agile software development world.

Thanks again for reading!

Great slide shows from Pathfinder

I came across these two great presentations about Agile on the Pathfinder blog, which is something I check from time to time being an Agile development shop in Chicago.

The first slide show is about integrating design in to the Agile process.  Something that is not really addressed in the Agile Manifesto, and is something I have posted about before.  It is critical area for Agile BA’s to address because the dive in and deliver functional code approach of Agile is great, but can lead to a very haphazard design with no clear vision.

The second one on Writing User Driven Requirements just really helped bring me back again to always thinking about the user.  I am certainly prone to thinking about business needs, or developer/technology constraints only, but the user should always stay front and center.

The Integration of Design and Agile Development

View more presentations from Pathfinder Development.

Writing User-Driven Requirements

View more presentations from Pathfinder Development.

The BA and Expectation Setting

The expectation gap

Expectations can destroy a project.  If the stakeholders have inflated, unrealistic expectations, regardless of the projects final deliverable, it will be classified as a failure.  The stakeholders will be disappointed and the project team will be demoralized.  The BA must play the role of project realist and ground the stakeholders, tethering them to the true idea of what the final deliverable will be.  The BA is uniquely positioned to fulfill this “Expectation Enforcer” role because of their requirements gathering responsibilities.

In my current BA role implementing a SaaS product, this is particularly critical.  I am the face of the company and product following the successful sales cycle, where they have been courted and wooed with the promises of time and cost savings and a great user experience.  During the 2-day requirements gathering meeting which follows the sales to implementation hand-off, one of the big parts of my job is not just gathering functional requirements and building the stakeholder relationship, but also gradually and carefully grounding those expectations which are often floating in the stratosphere.

This is a very tricky, balancing act that requires the BA to use all the soft skills they have at their disposal.  The customer’s enthusiasm and eagerness needs to be maintained and nurtured. Kill that now and you set up a long and difficult road for the project.  But let them run free and unchecked and you have a bigger problem and will set up the project to fail.

Expectation setting must not mean be negative.  The chips and knocks to their ideal of the project must happen organically and naturally as the conversation develops and the requirements are gathered.  It is because of this that I feel the BA is perfectly suited to the “Expectation Enforcer”.

With each requirement elicited comes the opportunity to gauge what the customer is expecting.

 

The BA must address each and every one of these expectations.  Probing, questioning, and resetting the scene to approach the problem from a new perspective, just as you would for a functional requirement.  As this discussion progresses you must latch on to what to what is possible, and enthusiastically confirm that assertion.  As we all know, start with a positive before delivering less favorable news.  Then carefully bring the customer down out of the cloud, ensuring they understand the realities of the project.  Whether that be the customization limitations of an existing SaaS product, or the constraints of a new development project, where cost, time or scope may mean their expectation cannot be met.

As is so often the case, using visuals greatly assists the process.  Working with a SaaS product, I use the requirements meeting to run demos in a test database, and show exactly what it is they are getting at every turn.  This works really well at transferring the enthusiasm from the ideal in their head, to how it will actually look and work.

Often the functionality is as they expected, it just works in a different way to the mental model they had developed during the sales cycle.

If working on a new development project, the principles of Agile and User Centered Design will play a big part in reigning in the expectations also.  Delivering working products quickly, soliciting constant stakeholder feedback, testing and iterating, will make sure that the customer understands quickly the realities of the project.  If you are working on a waterfall project (I feel for you), showing prototypes and using whatever visuals you have to hand as the project develops will help fend off the “this isn’t what we expected” comment when the product is delivered.

I would love to hear other BA’s opinions on this topic, particularly those working on new development projects, and how you approach this critical issue.

Thanks as always for reading.

Agile and User Centered Design

Nielsen Norman Group

This new article from Jakob Nielsen was an interesting read. It relates back, in a roundabout way if you really squint at it from a distance, to my previous posts (here and here) on where the Business Analyst fits in to the User Centered Design (UCD) process. Nielsen is looking at the problem from the perspective of how UCD fits in to the Agile development lifecycle. The focus on a rapid sprint style of development leaves little room for user engagement and testing. Furthermore the concentration on small sprints to achieve functionality can be at the expense of a unified, user-focused design and information architecture. Unless of course that UCD is integrated in to the project from the beginning. This is Nielsen’s point.

The BA gets involved in many of the areas that UCD preaches (requirements gathering, wireframing, information structure, process flow etc.) but he/she is not a designer, so my query was how they fit together? Nielsen makes this comment:

“it’s important to designate a gatekeeper to track requirements and communications between the UX team and the other project teams to keep everybody on track (even though those tracks are parallel).”

This would be a natural starting point for a BA to again be that bridge between two groups. Although it sounds like a Project Manager type role at first glance, I see greater scope for engagement and influence in the project, and so more of a BA type role. To be the “gatekeeper” between the UCD team and the development team. To integrate the user and design requirements from the UCD side, and working within the information architecture and design principals, bringing that to bear on the functional requirements and delivering that to the development team.

Just a thought.

Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process

I recently suggested to my boss a way to incorporate a process flow diagram technique in to our requirements gathering process. She liked the idea and allowed me to run a pilot at my last requirements gathering meetings. This is Part one of two articles documenting my experience.

As an Implementation Consultant for a SaaS product, the big kick-off for each project is a 2-day meeting at the customer site. This is a requirements gathering session driven entirely by an online tool that ensures I ask all the critical questions so I can generate the Business Requirements Documents and have the product configured. This question & answer, tool driven process is part of a broader Six Sigma, repeatable and reliable implementation path that the company has invested heavily in over the recent past. This in turn generates lots of data points, measurable and reportable milestones which the QA team use as a stick to beat us lowly Implementation Consultants with when we don’t meet them 🙂

However I felt as though this drive towards fully quantifiable actions and processes had resulted in a very stale and un-engaging requirements meeting. The tool forced the meeting away from a qualitative semi-structured discussion, in to a repetitive question and answer session…for two days!!

• Where was the consultative approach our implementation procedure and job title highlights?
• Where was the business process analysis?
• Where was the free-flowing discussion and use of more traditional BA methods of enquiry and elicitation?

My concerns at this particular issue possibly taps in to a broader problem of operational efficiency programs, such as Six Sigma, throttling fuzzy, qualitative procedures, but that was not my problem to address.  However I saw a great opportunity to include a visualization technique to capture the customers existing workflow that would be directly affected by the new software I am implementing. What I proposed was a business process diagram method, but what that would look like I had no idea at the time.

The key objectives were:

1. It must be quick and simple to draw / develop in real-time in front of the customer.
2. It must generate discussion and allow the customer to walk through the process, as it exists today, with no consideration for how it will change with the new software, or more in-depth technical considerations.

Process Flow Diagram Example

This is the example I developed after some online research (thanks to David Morris @GreySkinnedBoy on Twitter for pointing me to the BPMN) and showed to my boss. It builds on a swim lane type method although it will not conform to the linear timeline aspect normally the case with swim lane diagrams.

My hope is that this high level overview and story telling on the customer’s part will elicit requirements that would normally go undiscovered until later in the process. I also want to create a then and now document so the customer will know how the process will look at the end of the implementation, as well as a proposed process flow diagram if efficiency saving options are open following analysis after the meeting.

Overall I hope the introduction of a visual artifact will offer both value to the customer, improve the requirements gathering process and offer more opportunity for real value add consultative work.

Look out for Part 2 next week to see how the pilot went.

Does the BA look at the user experience?

A paper website prototype

Just a quick follow up to my last post which aimed to gather comments clarifying a couple of points.  What are the key functional differences between the BA and Information Architect (IA) roles, and how the split falls between requirements gathering and user centered design (UCD).

I am an avid listener to the Spoolcast podcast from User Interface Enginerring (UIE).  It is really informative and Jared Spool always has some great guests discussing UCD and UX topics. One of the recent guests, Todd Zaki Warfel, was talking about prototyping experiences, and during this discussion he touched on the very same role definition issue. Jared at one point posed the question to Todd, does the BA in even look at the user experience? This brought up some interesting points I wanted to share.

Todd felt that the BA’s typical remit on a project was functionality.  What functional requirements does the product need to fulfil.  So although the BA is involved in the design of prototypes, he saw these as being on the wireframe, boxes and arrows, Visio end of the spectrum. A prototype designed to show that the functional requirements elicited from the users and stakeholders will be met, and visually how those functions will look, in their rawest form.

However an Information Architect or User Interface Designer will approach building the prototype by trying to take it that much closer to the final look and feel of the site will be.  Again the functionality will be there, but there would be more care and attention to the usability and user experience with the site.  He also felt that the designer would be more willing to take a risk and create something very new, whereas the BA may be more inclined to stick to existing structures.  He used the specific example of the designer adding AJAX type aspects to their prototypes.

I certainly think that makes sense and although every BA and IA role will vary from company to company and project to project, I can see this line holding true the majority of times.  It does also back up my contention that in fact there is a fine line between the BA role and the UCD process and that the two sides could easily be joined if necessary.  This provides excellent room for growth in a BA’s armory if they can bring in valuable usability and user design techniques and perspectives to the requirement’s gathering remit. Particularly when expressing those requirements visually, which always seems to be the best way to really engage the stakeholders in the requirement’s process as they start to see the result to all the questioning.

Why business analysis?

I just read this article in Wired (love that magazine) and it got me all jazzed up and for a few minutes I couldn’t understand why. But then it dawned on me, it taps in to the very reason I sought out the role of Business Analyst even before I knew the role existed.

The article talks about the internet revolution resulting in a “good enuf” or lo-fi mentality. In particular it sites the MP3 revolution of the music industry. Music insiders scoffed at the thought of a lower grade music format when the whole industry had been striving for excellence in this area and was happily wallowing in the superiority of CD quality sound over vinyl. But the MP3 music file turned everything on its head. It tapped into an unknown or at least overlooked critical requirement of the music consumer. Shareability. All of sudden these inferior files were changing the face of music. One of the company’s that first realized this ground shift in user requirements was Apple and I can certainly argue that the very reason I am able to type this blog on my iPhone is because of the success of Apples MP3 business, iTunes and iPod.

This is what fascinates me about the BA role and why it is so important. Without a business focussed technology advocate committed to probing for user requirements the product can just end up being the baby of one of the internal groups, the developers, the designers/marketing or the business. Either way the most important group has been missed, the user. So unless you have someone pushing and asking the right questions you may just be missing an MP3/iPod type game changing product. That is what excites me about the BA role and why I think it is such a fascinating area, especially Agile methodologies and user centered design which I am learning more about now and will blog about soon.