Visualising your backlog: Impact Mapping

This post is the first in a 2 part series on visualising your product backlog. The second post will look at Story Mapping.

Recently on a trip to Sweden I was introduced to Impact Mapping, sometimes refereed to as effect mapping, as a collaborative work-shopping technique for identifying software features and mapping them back to organisational goals and user personas. The following article is a summary of the technique, as described in the book Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, along with a mix of my own observations from being involved in facilitated Impact Map sessions.

So what is impact mapping?

Well according to Gojko Adzic, an Impact Map is [1]:

A visualisation of scope and underlying assumptionsm create collaboratively by senior technical and business people. It is a mind-map grown during a facilitated discussion

Impact Maps can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.

How do I impact map?

Working your way through the following questions with your team or customer will allow you to build up an impact map from scratch. These are often best achieved in a facilitated workshop environment with a number of key stakeholders represented.


Defining the business goals is essential for any project and its the focus of Impact Maps. Why are we doing this? What is the goal that we are trying to achieve above all else?

Goal definition is about understanding the problem, not the solution. It should not be focused on specifically creating a product or application, rather explaining why its existence would be useful. It can be useful to try and tie the goal to the organisations value chain.


  • Increase online conversions by 15% in the next quarter
  • Attract 20% more customers in the next financial year


The first branch of an impact map looks at actors. For anyone who has spent some time with UML or traditional use cases you will know that actors can range from end-users and external suppliers to third-party applications or systems. Try and capture decision makers and those able to achieve the goal you defined or aid/block it from being achieved by others.

Consider the following questions at this stage:

  • Who can produce the desired effect? Who can obstruct it?
  • Who are the consumers or users of our product?
  • Who will be impacted by it?

These are the actors who can influence the outcome of your goal.


  • Students with a tablet device or smart phone in the classroom
  • Corporate employees with access to the secure drive


The second branch level of an impact map sets the actors in the perspective of our business goal. Don’t list all the activities that an actor might want to take, just the ones that are focused on achieving your goal.

Consider the following questions at this stage:

  • How should our actors’ behavior change?
  • How can they help us to achieve the goal?
  • How can they obstruct or prevent us from succeeding?

These are the impacts that we’re trying to create. Note: They are not product features.


  • Get faster access to accurate information
  • Have access to a wider network of colleagues to collaborate with


Once you have answered the goal, who and how questions you can start to consider and define your scope. This is the third branch level of your impact map and starts to identify the top level features of your product.

Consider the following questions at this stage:

  • What can we do, as an organisation or a delivery team, to support the required impacts?
  • What is the minimum that you can deliver to achieve your goal

These are the deliverables, software features and organisational activities. Do you not get too detailed at this stage and consider what the shortest route is through your map to the goal. It is very unlikely, and is potentially not a wise investment, to deliver all the features identified in your map.


  • Product galleries
  • Online purchasing


This is a section that I have added but its a step that I find useful to help understand how a feature will help the organisation to achieve their goals. Agile uses the phrase “Definition of done” and in a similar way I like to think about “What success looks like”.

Consider the following questions at this stage:

  • How will you know when your goal has been achieved?
  • What action or level of engagement will signify a success for your feature?
  • How long will it take to get usable data from this feature?

The outputs from these questions will help formulate your measures or metrics. Where possible you should measure the smallest individual unit Avoid vanity measures, page views and impressions are worthless unless they prove an increase in conversion or engagement from your intended users.


  • A completed signup form
  • A social media share

What are the outcomes?

In Adzic’s book he describes deliverables as being features, lines of code that helps organisations in achieving their goals, and of course he is right. However, I’ve often found it’s useful to understand at what point your Impact Map will be ‘finished’ and what the immediate deliverable from the exercise are.

Firstly if you are creating your Impact Map in a workshop then it will be produced within a timebox and will most likely be completed within the one session. Impact Maps are collaborative artifacts and unless you have all your stakeholder representatives available after the workshop, it’s not wise to carry on developing them in isolation.

Secondly, the largest deliverable from me as a business analyst are a prioritised list of features and measures, mapped against their actors (or personas) and goals. This allows you to quickly slice your Impact Map into a product backlog, understanding that what you have is probably high level epics that will require some breaking down into smaller stories.


The diagram above shows how you can map the who, how & what into stories that can be worked up.

What do I need to impact map?

When I first drafted the outline of this post my intention had been to discuss different types of mind-mapping software here. And for the record, I use Xmind and have had some great results with it.

However, having written this post now, it’s clear to me that what you need in order to effectively Impact Map is a good mix of stakeholders who can represent both your organisations goals and your users needs. Without access to them you will not produce an effect map that adds real value and your roadmap and backlog will be flawed from the start.

Impact Mapping: Making a big impact with software products and projects by Gojko Adzic

If you’re interested in Impact Mapping you’ll need to get a copy of Adzic’s book. This colourful and illustrative book take you through the basics needed to facilitate and create an Impact Map for your team or customers.

[1] Adzic, Gojko. 2012. “Impact Mapping.” [online].

Workshop Facilitation: Planning & Delivering

During a recent job interview I was asked to demonstrate my workshop skills. The company supplied some background about the project and the domain, along with a list of stakeholders that would be present in the workshop. I had 45 minutes to maximise my impact and capture some requirements, show some value add and write up some user stories. I was nervous.

Now this is a scenario I’ve been in 50 or 60 times in my professional career but never had I sat and thought “What is my workshop methodology?”, “What process am I going to follow to ensure requirements are captured systematically and to a high standard?”.

I turned to my trusty Business Analyst Handbook, flicked to the chapter on workshops and to my shock the advice was as follows:

  1. Open workshop
  2. Conduct workshop
  3. Close workshop

Well the above was useful, but I’d been successfully doing that bit for sometime now, I wanted a bit more.

I settled on some simple areas to focus on, that I felt could easily be reused as a basis for any workshop. They are as follows:

  • Why?
  • What?
  • How?

You can use this technique on a whiteboard, flip chart, with different colour post-it notes or index cards.

I prefer using A1 flip chart paper stuck to the wall, laid out as the diagram shows. The reason for this is quite simple, after the workshop you have a physical artefact to store, reference, review in any future workshops or conversations.

Workshop Diagram

Workshop capture screens. Each section represents a single A1 flip chart page.


Like all good business analysts my first thought was about the goal, the value, the vision.

I came up with the following questions:

  • Why are we doing this project?
  • What value will it add to our product and to our customer?
  • What is the vision for this project?

I identified that the Product Owner was probably the best-suited stakeholder to capture this information from and assigned a portion of the workshops time to this activity.

In my experience the sorts of answers that you get in this phase of a workshop are around business need. They often take the form of “We want to drive/increase traffic…”, “We want to increase conversions/revenue…” or “We want to save some money…”.


The next area I focused on what what is being built. This might seem like quite an obvious point but it’s important to capture what your stakeholders are expecting to see built. If you fail to do this you may have stakeholders with falsely set expectation from the very start of the project.

Some of the questions I asked at this stage are:

  • What are we building?
  • What functionality is it going to have?
  • What is it going to look like?

Try and steer clear of any questions that ask about the technical implementation. Some projects will be bound by technology constraints from the outset, but as a BA try and remain as agnostic from the technology being used until you understand Why the project is needed and What is being built, only then can you pick the most appropriate technology.

In this part of the workshop it may be appropriate to draw some process flows or sketch some wireframes of the interface design. I identified that the UX consultant was probably the best stakeholder to capture this information from.


By this stage you should now have a good idea about the project’s vision and the goals that it is attempting to achieve. You should also have a good understanding of what will be implemented during the project. This phase of the workshop gets down to the following:

  • How are we going to build it? Technology/Platform?
  • How are we going to resource the project? Internal/External staff
  • How will we know when the project is finished? Definition of done?

This is the time to discuss technical implementation of the project and any constraints that could be present during project delivery. All stakeholders will have input at this phase but Development/Technical leads and Product owner/managers will probably lead this phase.

Risks & Issues

This section is not a formal phase of the workshop, it’s something that runs in parallel to the previous 3 phases.

Those who have come from a project management background will be used to managing RAID logs. Now I’m not suggesting that as a BA you look to maintain a RAID log but there are often times during a workshop that you will capture feedback or information that needs to be recorded but doesn’t really fit into any of the above areas. These are sometimes non-functional requirements or constraints to the project.

The sorts of things that you will hear during your workshop that could be recorded as a risk or issue

  • All page loads must happen in under 1 second
  • The QA team need 4 weeks notice to write test scripts
  • A project manager has not yet been identified for this project


Workshops are a great tool for facilitating requirements collaboratively. They can be used to both understand a problem and to communicate a solution. By bringing together a range of stakeholders from across the business and delivery team it allows for all parties to be part of the solution. This can have a really positive effect on buy-in and stakeholder ownership of the project, which can only be a benefit.

Getting From User Stories to UX

Recently I wrote about User Stories and how card based software development can help identify ‘clear, brief descriptions of functionality as described from the perspective of a user’.

Today I want to look at how User Stories or ‘Stories’ can impact the user interface (UI) design and user experience (UX) of a software product.

So what is UX?
Don Norman (2007), Nielson Norman Group, describes it as

All aspects of a person’s experience with the system including industrial design graphics, the interface, the physical interaction and the manual.

I like this definition. It goes beyond the traditional Human Computer Interaction (HCI) thinking of physical device design. It goes beyond the point of how a user engages with a mouse and keyboard to get to the site or system and focuses on the software design and how the user interacts with it.

While there are many approaches available to User Experience Designers, Business Analysts and Software Designers, I’m going to be describing my approach to implementing UX in agile projects. I’m going to attempt to directly map these activities to the IIBA’s BABOK V2:

  • Elicitation
    • Persona Development
    • Story Writing
  • Analysis
    • Prototyping
    • Creative design and review
  • Communication
    • Managing Stories
  • Solution Assessment and Validation
    • Implementation and testing


Persona Development

Early last year I wrote about Users, Roles, and Personas and how they can help you as a BA to understand the users that you are designing systems and solutions for.

Stories are written from the human perspective, e.g. As a user I want to be able to do this or that. This is the shift I mentioned earlier from some of the more traditional “Systems Thinking” where we modelled what the system wanted to do. However, we can take this further by integrating Personas, by making the Persona the voice of the story.Watch Full Movie Online Streaming Online and Download

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas. Let’s user a Facebook user, Rick, as our example. After modeling Rick and working up a relevant Persona, we can now leverage that in how we create and talk about our stories. For example, we can add a Persona prefix to our story statements:

Rick Says:
As a User
I Want To upload a photo
So That other users can view it

With this short prefix, we’ve both helped to make the story feel real and made a connection to a particular user that will perform this interaction. As we have conversations about this story we can talk about what Rick would want or not want, rather than what some anonymous and disembodied Facebook user.

Story Writing

In a recent post I covered the process of writing user stories using the Card, Conversation, Confirmation format. While I’m not going to cover the entire topic again here I’d like to stress the importance of getting real users to help write stories.

It’s also important to try and separate out design and requirements until you start to prototype and work on design concepts. Try to avoid allowing users to write the sorts of stories where they dictate UI implementation to you. These can often be expressed as “I want to ‘click on a button’ to” or “I want to ‘select from a list’ something”. In my experience a user is trying to help you, but often they are describing a legacy systems implementation of a particular feature and this can distract from why the action is being preformed and focus too much on the how the action will be performed.



I could write an entire post on prototyping, and probably should. I am a real advocate of both low fidelity (lo-fi, often used to describe hand drawn or basic static wireframes) and high fidelity (hi-fi, often used to describe interactive prototypes). I am always amazed at how much feedback you can get from users by showing mock-ups and prototypes. As a caveat to this, my last note about not mixing requirements capture and design still stands. Try not to just sketch a quick solution in your notepad and show it to users in workshops. This can sometimes lead to a false setting of expectation and doesn’t allow you to properly test and capture feedback on the design.

Prototypes can perform two key functions:
1. They can be used to give early validation to a solution. Remember, user stories are small chunks of a bigger system. We can get validation feedback that the feature is correct, without having to have every page and feature implemented.

  1. They allow you to observe the user’s interaction with the proposed solution. I often find this activity more valuable then a users verbal feedback. This could take place in the form of formal lab testing scenario or as informal stakeholder reviews.

Creative design and review

In my experience visual treatment is usually applied to a prototype after it has been tested and signed off by the client. However, I know some teams don’t differentiate between the prototyping and creative stages in the process. To these teams the development of the prototype and visual treatment is the same stage, and their prototypes use the brand guidelines and colour pallet to allow for a much richer experience.

This is one of the exciting things about UX. As we move away from traditional HCI, UX is much more about the emotional experience than the physical one. UX is not just about demonstrating functionality ie. “If I click this then…” but far more about the journey that you are talking the user on to make engaging with your feature an enjoyable one.

Visual treatments and concepts can be tested at this stage also. User-centered design (UCD) focuses on analysing and foreseeing how users are likely to use a product, but also in testing the validity of their assumptions in real world tests with actual users. This can be performed in labs or using a range of remote testing solutions.

Like other aspects of agile, this is an iterative process and may take a few rounds of testing, feedback and implementation before the agreed design is agreed and put into production.


Managing Stories

There are a number of ways to manage stories, from story boards, spreadsheets and project management systems. While I don’t have a personal preference, I do use redmine for the electronic copy of my stories. Like other aspects of documentation on your project the important things to think about are:

  • Ease of collaboration
  • Visibility
  • Traceability

While it’s important to keep good documentation around your stories, these aren’t bound documents that BA’s working on traditional projects will be writing. It is important to think about how you can make them visible to the rest of the team and/or stakeholders. They should living documents, growing organically as more information comes to light.

The benefit of tracking these in a ticketing system like redmine is that you may even be able to offer traceability with the code repository. Other teams may check their stories and tests into SVN to live alongside the code.

Since my last post on the subject I have updated my base redmine user stories template to allow for some additional fields that you may want to capture when performing UX activities.

Solution Assessment and Validation

Implementation and testing

This is one area within the BABOK that I struggle with. While I obviously believe it’s important to validate a solution and test it, I’m not sure that I agree that this is a formal activity that happens at the end of the development life cycle. I think that the BABOK may be referring to a degree of formal signoff or UAT that takes place, however, on agile project my experience is that this happens on a much more regular occurrence.

Testing and validation of a solution can identify issues that can often be quickly and inexpensively corrected during the prototyping and design stages.


As Business Analysts we need to consider the use of such practices in our toolbox to help us communicate and demonstrate solutions to our clients or business teams. At the same time they can be used to collect rich feedback on a project before a single line of code is written.

BCS Manchester: Kanban Presentation

Finally I made it along to one of the BCS Manchester events. After re-joining the BCS last year this is the first of the local events that I’ve made it to, and it was excellent.

David Toon (@davidtoon83) presented his take on Kanban and took the group through the 4 principles of Kanban.

The group clearly had different levels of exposure in using Kanban and some used it for DevOps while others used it in a support role.

One of the things that struck me about Dave’s presentation was that he strongly advocated using it in conjunction with other methodologies such as SCRUM and even Waterfall…!

Anyway, the event was a success and the post-event beers went down well.

It looks like I may have been collared to d a write-up of the event so watch this space!
Clash of Clans Online Hack and Cheat

Kanban: Optimising for Predictability

On my last project we had a play with running a Kanban board. I’ve used Scrum on a number of occasions and am quite comfortable with writing User Stories and Tracking Estimates and Velocity but Kanban was something quite new.

Kanban is a JIT system that has its roots in the Toyota production system circa. 1940/50. It’s based on a simple queuing system that is intended to reduce the overall load of individual resources (designers, developers, testers, etc) by ensuring that packages are supplied to each resource just-in-time, preventing bottlenecks and/or too much slack in the process.

The Agile Extension to the BABOK says:

Kanban is a methodology for managing the flow of work to allow for evolutionary change.

There are 4 key aspects to implementing Kanban, they are:

  • Visualise the work
  • Limit work in progress (WIP)
  • Focus on flow
  • Continually Improve

Let’s look at those in a bit more details.

Visualise Workflow

Visualising your workflow involves getting the tasks required for a project or package of work up on a board, as this the interpretation of Kanban (カンバン?), literally meaning “signboard” or “billboard”. There are a number of electronic systems for this, but I find that getting a board up in a space that your team can get around adds great value and a great opportunity for collaboration amongst the team.

The board is divided into swim-lanes and cards or tasks move from left to right until completed. This gives the team, not just the project manager, visibility on where bottlenecks are building on the board.

Kanban Board
Figure 1: Kanban Board. Source: BABOK Agile Extension

Different teams will pick different names for their swim lanes but I think the above is a good starting point for lane names.

Limit work in progress (WIP)

Limiting work in progress is the process of determining the maximum number of cards that can be worked on in any swim-lane. In the example shown in Figure 1, we can assume there is a development limit of 2. That is to say that the total number of cards that can be across both Waiting for Dev and Dev can not exceed 2. If we look at testing and assume that the testers have a lane limit of 3 then the following is true:

  • Dev can not put anything else in to test until “Generate Receipt” is Done.
  • Dev can not ‘pull’ anything else from Analysis until they move at least one card into Testing.

As soon as a task is completed in testing a vacuum  is created and test can pull from development, development can pull from analysis and analysis can pull from the backlog.

Once you start to reduce WIP you start a continuous improvement cycle within the process. This allows you to make better decisions on your resourcing profile on the project.

Focus on flow

Flow can be measured using CFDs or Cumulative Flow Diagrams. These diagrams can be really useful when attempting to analyse flow through the board and identifying areas for improvement.

The following diagram shows a simple but accurate example of how a CFD can be used to show the amount of tasks in each lane over the duration of the project. we can see that at the beginning of the project the backlog was large (to-do), the in progress work was very small and there was no work completed. On days 6, 11, 20 and 24 deployments were made pushing work from in progress to done.

Figure 2: CFD. Source: Positive Incline (

Continually Improve

The CFD can be used as a tool to show the effects of any changes that you make to the team or your WIP policies throughout the duration of the project. Track if individual changes have a positive or negative effect on the flow through the board. At this stage you should be looking to optimise for more predictable flow.

The following may help for produce improvements:

  • Investing in CI tools to help your team deploy more regularly
  • Implementing WIP limits and Pull Conditions
  • Training developers to write tests for their code. This may improve quality and reduce the amount of time code sits in test
  • Increase resources in one of your skill areas

Every team understand its own pressures and resource/investment constraints. However, a CFD will help you optimise your flow within those constraints to produce a predictable flow of delivery.


Kanban is a very powerful tool for helping a team understand where bottlenecks are in production and gives tools to help track the effects changes to the pipeline may effect that bottleneck. Some of the best advice I had from a member of my team who had a lot of experience with Kanban was:

  1. Start with what you do now
  2. Agree to make a change
  3. Respect your core rules (wip limits)
  4. Get better!

User Stories: Card, Conversation, Confirmation

I’ve recently rediscovered my love for user stories. While some projects call for a formal, more traditional approach with strict documentation, others call for collaboration and quick results. It is this latter approach that user stories were designed for.

User stories are simple, clear, brief descriptions of functionality as described from the perspective of a user. Note: A User Story should not be mistaken for a Use Case. User stories in agile development can be useful to users and customers of the software. These user stories can then become the product backlog of an agile project.

When writing user stories I like to start with a pile of blank index cards and plenty of space to lay them out or a large board to stick them up. Ideally you will have with you a representative of your client (if this is not an internal project), like a product owner, project manager or BA. This allows for collaboration and discussion between the IT delivery team and the project owners or sponsors. I use the following as a guide for writing stories:

Front of Card
Front of Card
Back of Card
Back of Card


The aim of the card is to capture the following three areas:

As a [user], I want to [action/function], so that [value]

The simplicity of this template is important. I recently wrote about the Agile Manifesto, a guide to better interactions and collaborations. User stories production needs to be accessible to everyone and so this informal format helps to engage the entire project team to get involved.

Writing these out on an index card allows them to be produced quickly, discussed, adapted and moved around based on priority.

Here are some example stories that I have created for Facebook:

As a User
I Want To search by name
So That I can find my friends and associates
As a User
I Want To upload a photo
So That other users can view it

The first part of the card defines the Who, What and Why. But it’s not all the detail. This is where the conversation comes in.


The conversation part of the story is an opportunity to elaborate on the details captured at the previous stage. In some planning meetings this will happen as the card is being written. In other cases this conversation will grow dynamically as both developers and clients understanding of the feature to be implemented improves. It allows for continuous dialogue around a feature, with the detail being recoded here.

For example, I previously used a photo upload user story, and have decide that there are actually multiple things that can happen, so we split them, and expand on them:

As a User, I want to upload a photo from my local machine so that any users can view it.


  • There will be an upload button at the top of my profile page
  • There will be a file size limit of 25MB
  • The supported formats are: jpeg, png, gif and bmp
As a User, I want to tag my friends and write a caption before publishing a photo to save myself time.


  • The fields that can be edited are: caption, location, tags
  • On save the image will be published

In many case a card will go through an analysis or elaboration step prior to making it into development. It is often at this stage that the conversation section will be completed. I find it important to be as verbose as possible here, providing the developer with all the detail required to complete the feature. It is at this point I ensure that the card is duplicated into an electronic format. I have seen some good spreadsheets for managing stories but I favour ticket tracking software as it allows documents to be attached. These could be process flows, business logic, designs or wireframes. I keep the paper copy of the card and reference the ticket ID on it so that there is a link between the physical asset and the electronic copy. I use the following Redmine User Story Template to help me format my tickets.


The confirmation part of the card is a space for a test case to go. These are steps or scenarios that help a developer test and a customer or user perform UAT. If your development team are undertaking Test Driven Development (TDD) these steps will form the basis of their test writing.

  1. Click the “Upload” button.
  2. Specify a picture file to upload.
    1. Check that .jpg, .png, .gif and .bmp extensions are supported.
    2. Check that other filetypes aren’t able to be uploaded.
    3. Check that files larger than 25MB results in an error.
  3. Click “Upload Photo”.

I try and write the confirmation parts of my story as I am having the conversation with the client or customer. Acceptance testing can allow you to limit scope of the feature and make you more confident in the estimate supplied. In the above card a requirement was captured for 4 different file formats. If your customer wants to change this in the future, agile allows for this, but until they do its part of the requirement that only 4 formats will be allowed. This allows us to define our Definition of Done, when all the conditions are met development can stop.


Writing user stories can be quick and productive. It removes the overhead of detailed static documentation and makes way for creativity and collaboration. However, there is a lot more to user stories then just writing cards. Previously I have written about Measuring and Monitoring Velocity and my next post will be on Story Maps.

BABOK Agile Extension for Business Analysts

Today the IIBA launched its new Agile Extension to the BABOK® Guide. Get it at

The BABOK® is the IIBA’s Business Analyst Book of Knowledge that is the first formal approach of defining and documenting what the role of a business analyst does.

The purpose of this extension is to:Watch Full Movie Online Streaming Online and Download

  • Highlight the importance of business analysis practices in an agile context
  • Show how business analysis is performed in agile lifecycles
  • Offer key principles that should guide business analysis practice in agile environments
  • Develop existing business analysis tasks, and existing techniques and show how they are useful in an agile context
  • Give information on new techniques and additional information on existing techniques

As someone that has been working in this space for some time, attempting to adapt my existing skillset and knowledge to an agile environment,

I am really excited. I’m about half way through and I suspect that I’ll read it and re-read it.

It’s exciting to see agile adoption on the increase and this extension book will help BA’s feel equipped to work with developers and clients who are actively using SCRUM, XP or KANBAN.

My hope is to prepare some posts and feedback from what I’ve read in the extension, I’m also keen to see how my own approaches compare to those that have been outlined in the guide.

Managing Change – The Agile Way

Today I came out of one of our showcase/demo sessions with a client and his stakeholders. These are usually the points in the project that we all look forward to. Increased collaboration with our clients and the proximity of their office to ours has meant that we have a great rapport with the client’s team and these demo meetings act as an opportunity to impress the client and for the developers to get a few pats on the back.

However, today it was different. The client had brought in a new stakeholder and as we started the demo he put his hand up and said something that silenced me, he said “We don’t do it like that any more”. I was panicked and a little shocked. The guy apologised and clarified the position, “I’m new here I know but we’ve just been told by our supplier that we need to give them visibility on orders earlier in the sales pipeline, so the workflow needs reworking”.

My initial thoughts were that of worry. In traditional projects a conversation like this usually has cost and time implications intrinsically linked to it and I was worried about what I’d tell the developers and my boss.

Thankfully the team allowed me to complete my demo and then we got the whiteboard out and started reworking what we had implemented to help tackle this 11th hour requirement. By doing it in this way we were able to remain professional while being adaptive to change with the client.

The Poster

When we got back to the office I had a look closer at the ThoughtWorks Agile Manifesto poster that we had on the wall. It reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
    (Well I’d been there, sat with the team and interacted with them – tick)
  • Working software over comprehensive documentation
    (The client wants working software – the docs were out of date but the software didnt have to be – tick)
  • Customer collaboration over contract negotiation
    (I did’t scream ‘Change Request’ even though I wanted to… we worked it out – tick)
  • Responding to change over following a plan
    (We responded to the change over the plan – tick. However, if it hadn’t been for the plan we wouldn’t have identified the change. I think it’s important to plan – but to use it as a guide, not a law book) 

Today it all made sense. The agile manifesto was written to help people in exactly the same boat as I had found myself in.


Becoming Riders of Paradox

ThoughtWorks Live 2011Last week I had the pleasure of attending ThoughtWorks Live 2011 in London’s St Martin’s Lane hotel. The conference, entitled Continuous Delivery: Push the button, was a showcase of ThoughtWorks thinking on how to become truly agile through the implementation of Continuous Delivery and Continuous Deployment.

Among the speakers were heavyweights such as Martin Fowler, ThoughtWorks Chief Scientist & Roy Singham, ThoughtWorks Founder & Chairman – positioning ThoughtWorks as not only global experts but as global educators, both practically and aspirationally.

Riding Paradox

Paradox Horse
"Paradox" by Michael Bergt

A real favourite for me was a presentation given by ThoughtWorks Studio’s Managing Director, Cyndi Mitchell on Adaptive Leadership: Accelerating enterprise agility, based on Jim Highsmith’s whitepaper of the same name. In the presentation Cyndi discussed a number of challenges that leaders face in being adaptive. The real eureka moment for me, in both the presentation and the whitepaper, was the concept of Riding Paradox. We were encouraged to be ‘And’ rather than ‘Or’ leaders, inclusive of elements from multiple methodologies that can add value and work together for the benefit of the project. No one methodology has it 100% right and we should look to take aspects of different practices and thinking and incorporate them more. A quote from Rotman summed it up well “Integrative Thinking is the ability to constructively face the tensions of opposing models, and instead of choosing one at the expense of the other, generating a creative resolution of the tension in the form of a new model that contains elements of the both models, but is superior to each“.

Highsmith discusses in his whitepaper “The paradox horse seems always to be going in opposite directions at the same time. Furthermore, the leader is exposed, drawn by the traditional norms of many organizations in which it’s OK to be wrong, but not OK to be uncertain“.

As a Business Analyst I often find myself in a similar position, for two reasons. Firstly, due to the nature of my role I report into my Managing Director for the purpose of sales targets and planning, while reporting into my Technical Director for the purpose of scoping and quality assurance. It can often feel like attempting to serve two masters, serving two areas of the business who sometimes have opposing expectations.

Secondly, clients can sometimes be prescriptive about the methodology that their software project should use. This is rarely based on thoughtful consideration of stakeholder needs, rather that the client has heard a buzz word or has used that methodology on a previous project and feels safe with it. As an example, I have had clients come to me and say “We want to use Prince2”, for no other reason then a third-party advisor has suggested it would ‘be best’. This leads to lengthy planning and scoping phases of work up-front which the client is happy with. However, once the project moves into production the development team opt to take an agile approach to the job, breaking down my long specification into chapters – renaming them iterations and delivering little and often.Watch Full Movie Online Streaming Online and Download

At the same conference one of the speakers, Dave West from Forrester, coined the phrase “Water-Scrum-Fall” that perfectly describes this idea that scoping happens, the development team run off with an agile approach and then the final mile of the project reverts back to a very formalised sign-off process.

I’m excited by what I’ve heard at the conference and challenged to implement changes in my working practice. Lets hope I can attempt to ride paradox without falling off!

Rotman. (n.d.). Integrative Thinking. Retrieved from Rotman Business School [online]. Available from:

Highsmith, Jim. 2011. Adaptive Leadership: Accelerating enterprise agility [online]. Available from:

Image from: Jim Highsmith: “And” Leadership.

Measuring and Monitoring Velocity

Recently, I have been doing some work with User Stories. As a result the developers and I have started to estimate user stories using story points. This is a good way to allow a team of developers to collaboratively estimate the complexity of a piece of functionality and how long it will take to implement.

The question was asked about how we make our progress visible to internal and external stakeholders of the project. Unlike a traditional waterfall project there is no gantt chart or detailed project plan, only a series of iterations and some expected deliverables for each iteration. This lead us to think about how many story points we were expecting to complete in any single iteration.

Many of the projects that I have worked on in the past use Burndown Charts, but most of them were produced out of a project management tool. I decided to take the user stories that I had from the current project and have a go at producing my own Burndown Charts.

Using Google Docs I was able to take data from the user stories, broken down into the 5 iterations, or sprints as some prefer, and produce a burndown chart.

Traditional Burndown Chart
Traditional Burndown Chart

However, when I looked at it I couldn’t help but think that it looked too good. Like the project had been too easy. I went over my notes and I was reminded of two things that happened during the project:

  1. The teams estimates changed
  2. Scope creep set in

What that actually meant was that while the project looked like it had gone really quickly and that we had over estimated the user stories in each iteration, there had been some changes mid-project that we had negotiated and these had effected the overall number of story points in the project. To better show this I have produced a second chart that I think helps stakeholders see the movement in scope in relation to the burndown.

Burndown (including scope creep)
Burndown (including scope creep)

The addition of the ‘scope’ line shows the burn down in a slightly different light.

At the end of iteration 1 (i1) the developers are behind of where they should be. Being an iteration in and being able to rework their estimations they deem some tasks to be more effort and increase their estimations to match. This saw an increase of 5 story points, 2.6% of the project.

At the end of iteration 2 (i2) the client team dropped a piece of functionality. We were able to cater for this change and thus removed 18 story points, 9.5% of the total project.

The rest of the project continues on its projected line but had there not been an additional line to show change the client team could have easily misunderstood why the project was in its current state.

I don’t know how people feel about using such charts and if hacking them to show more information is allowed. I believe strongly in giving clients as much useful information and feedback as is possible. It is important that a client team see a strong correlation between scope creep and effort. If the scope of a project is increased a project will, in most scenarios, take longer. However, if a scope is decreased then often there is time savings.

That last point about time is one thing that I should extend on. We struggled to take the conceptual theory of a story point, determine a velocity and then convert that to developer days. In the end we settled with estimating in developer hours, so 1 story point = 1 dev hour. This seems like a bit of a cheat and not as pure as intended, if anyone has suggestions on how to improved project estimations I’d love to hear from you.