I usually try and keep these posts technology agnostic, but when it comes to wireframing it has to be said that I’m an Axure fanboy. I know there are lots of other great tools out there but this is the one that I’ve settled on.
Axure has a built-in specification generator, which reminds me of projects where the quality of my deliverables were measured by the length of the documents. However, I’ve been playing with some of these settings in order to turn the built-in features into something a bit more useful. Here’s what I discovered:
The Annotations Widget
This is the Annotations panel within the Widget Properties Pane (you can open it using ctrl+1). By default it has lots of options, covering a range of needs from the features status, risk, owner and benefit etc. While this is all very useful it can feel a bit overwhelming if you don’t know all that information or feel like you’re duplicating effort by repeating info that is already being captured against your user stories. To help me capture what I need, without writing war and peace, I’ve opted for the following fields:
An example of the annotation properties with Axure 6.5
<dl>
Description
I use this field to describe what the feature is, nothing fancy. “This is a drop down picker that allows a user to select their timezone”.
OnClick
This field describes what the user can expect to happen when they interact/click on the feature. “Onclick the user will be presented with a list of timezones to select from. By default ‘GMT London’ should be selected”.
Design Logic
I use this field to describe when the feature will be shown and any edge cases where the design or layout may change. “The first time the user uses the application they should set their timezone. On returning to the application this should already be set and display the option the user has stored previously in their preferences”.
On generating the prototype it builds into HTML and adds a small icon over the top right hand corner of the feature. If you hover over them your cursor will change to have a ‘?’.
When you click on the note it will open up and can be moved around the page, in order to prevent it to obscure the feature it is describing.
You can play around with combinations of fields that you use and even have different ones saved for different clients. Any fields that are left blank when annotating your prototype will not be shown once the HTML is generated.
Sharing Axure Files
If you’ve not seen it yet I strongly recommend Axure Share. It allows you to store and share your Axure prototypes and even has functionality to allow users to discuss elements on the prototype.
Read More…
If you want to find out more about the Axure annotations feature why not check out the following:
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.
Why
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.
Examples:
Increase online conversions by 15% in the next quarter
Attract 20% more customers in the next financial year
Who
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.
Examples:
Students with a tablet device or smart phone in the classroom
Corporate employees with access to the secure drive
How
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.
Examples:
Get faster access to accurate information
Have access to a wider network of colleagues to collaborate with
What
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.
Examples:
Product galleries
Online purchasing
When
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.
Examples:
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.
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.
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:
Open workshop
Conduct workshop
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 capture screens. Each section represents a single A1 flip chart page.
Why?
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…”.
What?
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.
How?
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
Conclusion
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.
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
Elicitation
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.
Analysis
Prototyping
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.
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.
Communication
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.
Conclusion
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.
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.
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.
Really enjoyed @datoon83's #kanban talk @bcs_agile tonight. Some great discussions from the floor. Thanks for everyone's input.
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.
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.
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.
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.
Conclusion
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:
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
Back of Card
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.
Conversation
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.
Confirmation
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.
Click the “Upload” button.
Specify a picture file to upload.
Check that .jpg, .png, .gif and .bmp extensions are supported.
Check that other filetypes aren’t able to be uploaded.
Check that files larger than 25MB results in an error.
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.
Conclusion
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.
Today the IIBA launched its new Agile Extension to the BABOK® Guide. Get it at iiba.info/AgileExtension.
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.
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.
Last week I was thinking about how to capture and analyse business rules and data requirements for a current project. I’ve worked on a number of projects where the focus can often be on either rules or data, however focusing on one while leaving the other out can cause issues further on in the project life cycle. I’ve learnt this on previous Business Intelligence/Data Warehousing projects where over analysis of the data can lead analysts to start to ask more questions of the data then the end-users or owners ever wanted to ask, while key rules are not enforced.
A declaration of policy or conditions that must be satisfied…. In order to define, stream or enable our system or process behaviour. (Gottesdiener 2005)
Mary discusses 4 types of rules that can aid a BA in categorising rules and their corresponding data dependencies. These 4 rules are:
Term Rules
Fact Rules
Constraint Rules
Derived or Calculated Rules
I am listing them below more for my own reference benefit, but hopefully others will find them useful.
Term Rules
Defining nouns such as “Customer” or “Gift Card” is important. This task is not just for your glossary but for giving context to your system or process. We’re able to identify actors (Customer) from terms based rules and this helps us define the scope or boundary of the work to be undertaken.
Fact Rules
Fact rules are a two way relationship between terms rules. For example:
A purchase is paid for by a gift card
A gift card pays for purchases
These can be extended to use cardinalities
A purchase may be paid for by one or more gift cards
A gift card may be paid for by one or more purchases
As we identify fact rules we can determine data attributes. For example:
A customer has an address. An address is made up of address lines, city and location.
Defining these data types allows us to define the scope of the rule. For example we don’t want a second address line.
Constraint Rules
Constrain rules can be used to constrain the action of a rule. In this example an expiration date is added to the gift card.
gift card expiration date must be equal to or greater than purchase date.
Derived or Calculated Rule
A calculated rule allows us to derive new attributes from existing ones. For example:
A gift card date is calculated from the date of activation plus 365 days.
Gottesdiener, Ellen, The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. Goal/QPC, 2005
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.
On generating the prototype it builds into HTML and adds a small icon
over the top right hand corner of the feature. If you hover over them your cursor will change to have a ‘?’.
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?
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.
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.
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.
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”.
