Planning Poker

I have been using planning poker in our planning meetings for a while now and I get many people asking what it is and how does it work so I thought to write my expericence with planning poker.

Planning Poker is a technique used in agile software development for estimation. There are various ways it can be done but the most effective way is to do it with a cross functional team.

Before you start the estimation make sure you create (or bring an existing one) a user story, user story should be very small (possible independent from other functionality) and self explanatory, we do not use any fancy system to record user stories, in fact we use one of the oldest method ... on cards. The goal of this planning meeting is to estimate that user story.

In our work environment we use a cross functional team, we do not start estimation if we do not have at least one person from QA, development and BA team. The advantage of this mixture of skills is to be able to see the user story from each angle. BA usually kicks of the estimating meeting by explaining the user stories, depending upon the story other teams members may have questions like, what technology it will be developed in? Will there be any automated test? Etc.

Each member in the planning meeting is given a series of cards; we use 0.5, 1, 1.5, 2, 3 and 5. You can use any units you want, the units can be related to days, hours or some fictional units (some agile practitioners like to call them relative units of work).

Once the BA has explained the user story and everyone has asked their question, each of the team member picks one card from his/her deck. They do not show the card until everyone has finished picking their number, on one go everyone then displays the card. Most of the time the estimates from all of them will be within a small margin let’s say 2.5-3.5 in this case you can safely assume the estimate to be 3.

If for whatever reason the estimates are very different like one person is 2 and other person is 5, both that person gets the opportunity to explain their estimate, it may happen that the person with estimate 2 has some insight on the problem, it may also happen that the person with estimate 5 raises a very valid problem, based on the argument presented by all the parties you may play the estimate game again.

Acceptance Testing

Acceptance testing is the final testing done on the software prior to its final delivery. Please note that acceptance testing is different from user acceptance testing which is normally done by the customer or representative of the customer within the company.

Acceptance testing is sometimes also referred as functional test because each acceptance testing is also testing the functionality of the software.

Acceptance testing should be defined and agreed during the requirement phase of the project and is normally defined by the business customer as the minimum test to be executed before the delivery of the software. Some customer is hesitant or not technical enough to write the acceptance testing, that is when the BA comes in action, every requirement gathered during the investigation phase should be converted into acceptance testing. Best acceptance test criteria will be created when customer, BA, developer and tester get together, this will also avoid certain test to be run multiple time during the delivery.

Acceptance testing in Agile

Traditionally acceptance testing is done at the end of the project but in an agile environment acceptance tests will be defined and agreed at the beginning of every iteration. Every user story becomes a test and the story is not complete until it passes these acceptance criteria.
Acceptance test helps developer to understand the functionality from the user story. Make sure all the scenario in the user story is covered by the acceptance test. Each acceptance test should define the environment, inputs, steps and outputs for each user story. Make sure each acceptance test is understood and verified by the customer (this is very important if someone else is writing these test on customer’s behalf)

Iteration Retrospective

Retrospective is an agile process which allows the team to stop and look at what they have been doing and ways to improve.

There are many types of retrospective depending upon when it is done; if you do a retrospective at the end of the iteration it is called iteration retrospective.

The main goal of the retrospective is to discuss with the team what went wrong, why and how can we prevent it in the future. The outcome of the retrospective may change the way you execute the next iterations.

There are 3 fundamental questions which the team should be asking

• What went well in the iteration, which we should continue doing?
• What should we stop doing?
• What should we start doing?

Please note the order of the question it is very important for the team morale to talk about success first before discussing the bag things.

By discussing the problem and suggestion the team can change the way they run the next iteration and eventually grow and be more responsive and productive. A retrospective should be plan for about 30-40 minutes, ensure the time and location used is convenient for every team member to attend, this meeting should not be optional. Shareholder, Business Unit, SME, BA, Developer, QA in fact anyone and everyone who was involved in the iteration should be attending the meeting, you may invite customer in the meeting depending upon their involvement.

Retrospective should not be a blame and shame session, it is not about who did wrong, it should be all about how can the team improve based on the team experiences. Team members should not be scared to speak up and admit the things which were done wrong.

Get feedback from the team members about the retrospective to make the retrospective better for them and finally don’t forget to thank the team to be open and honest.

Preparing Business Case

Developing a new product or functionality involves ensuring the money is spent wisely and that there is proper ROI (Returns on the investment). A business case is a detailed report used by the stakeholder/sponsor to justify the need of the project. The report should provide all the relevant information in an easy to understand format. In some companies business case is a must to receive funding and go-ahead for the project.

A business case is used to support a particular course of action when there may be several different options; the most important aspect of the business case is the cost-benefit analysis.

Identify your audience early in the process; you will have to address each audience's need, concern, expectation and level of understanding in the document.

Cost Benefit Analysis should be broken down into two categories, 'Direct Costs' and 'Indirect Costs', list all the topics under each category. With my experience sponsor loves valuing in dollars, try to work out each of the cost and benefits in dollars.

Although there is no official format or one that works for everyone, I can suggest you to structure the document in the following section

• Background
• Effect/Risk of the problem
• Costs and Benefits
• Proposal
• Impact
• Conclusion/Recommendation

Other factors which should be considered in the business case are

• Financial (expense and revenue)
• Corporate commitment
• Quality
• Customer pressure/satisfaction
• Industry pressure
• Legal compliance

Finally these are some of the questions which should be answered in the business case document

• Why are we doing this project?
• What is the problem this project is trying to address?
• Are there any workarounds or alternates?
• What are business benefits?
• How are we going to solve the problem?
• How much it is going to cost and how long will it take?
• If we do this project, what are the risks?
• If we don’t do this project, what are the risks?
• If we need to measure success how will be measure it?

Try to answer the questions above in the document to create a good business case proposal. In the end of the document make sure you summarise the problem, costs and benefits of the proposed solution, the document should be structured to highlight that the benefits outweighs cost.

See you next time.

Crash Party

I know what springs to mind when you hear 'Crash Party', but I am not talking about gate crashing or going to a party you haven't been invited. I am talking about Crash party before the release of the software, so let me start by explaining what is a crash party and why there is a need for one?

Testing plays a crucial role in the successful delivery of today’s complex, heterogeneous, business-critical software systems, as software get more and more complicated, there is a need to improve quality which poses challenge to the QA team, crash party is yet another way to improve quality.

Crash party is another form of collaborative group testing when a group of people (Developers, BA, QA, Support) gets together for a limited amount of time and test the functionality of the product with the intention to find as many defects as possible, it works on a very simple principle that when multiple people are using the system in a non predictable way, they are bound to find workflows (along with defects) which hasn't been thought, documented and/or tested before. Some Crash party may use a predefined script (e.g. UAT ) for the testing. Crash party can also be used for load and stress testing.

Crash party is an excellent way to bring team members up to speed, get them familiar with the area they haven’t work before, and the most important thing is to make them feel a part of the entire product.

Each team member participating in the crash party may be given an area of the product to test. Give cards or paper to each team member to record the defects and the steps to reproduce it, I would highly recommend you to not introduce any electronic bug recording system during this process, the reason being it is easier to write it on a piece of paper and expand that later once the crash party is over.

One of key things to ensure in a crash party is to make sure that the test cases and/or areas are evenly distributed among the team members and to avoid repeated test steps. Also make sure you are not executing any steps which have already been tested by automated tools and regression testing. Always tell the team member the goal is to find what we haven’t found before, 'we don't know what we don't know'.

After the Crash Party is completed, compile a list of defects found during the process, there may be some defects reported due to incorrect data entry or workflow, make sure you discuss that with the BA to ensure the defect is still relevant. The next and the most important step is to prioritise the defects to be fixed before the release; the ones which can’t be fixed in the current release will be flagged for the next release.

Finally software testing is an art, testing practices have not changed since last few years, but the tools and techniques have, complete testing is infeasible, so try to implement quality at every stage of development.

Agile Vs Waterfall

I am pretty sure this topic has been discussed many times and is there a clear winner ... I guess not.
I have been working with waterfall methods all my life and more recently with agile, if I have to summarise they both have their advantages and disadvantages.

I thoroughly enjoyed doing analysis in a water fall method, partly because you were given the opportunity to think and discuss solution upfront, so more time was spend doing the requirements gathering this works really well where project has limited resource (time or money) and clear objective.

On the other hand the disadvantage with the waterfall method (more so in the current era) is that it is not as versatile as agile. Business are growing (and some of them are shrinking), as day goes by there are new competition in the market, new legislations and other factors which affect the company and needs to be responded immediately, in this type of environment agile allows quick and timely changes.
Agile also allows team to delivery solution to the QA team and possible to the customer quicker than the waterfall method.

Being ScrumMaster (Daily Scrum)

This week I was ScrumMaster, so that makes an interesting topic for me to talk about, one of the ScrumMaster's main job is to facilitate the daily scrum meeting, don’t forget ScrumMaster is also a member of the scrum team.

As a ScrumMaster make sure that the venue where Scrum meeting are held is consistent, changing venue can cause unnecessary delay, also do not change the time of daily Scrum, no matter what happens around in the company, daily scrum should happen at the same place, same time (it is ScrumMaster's job to ensure that everyone attends the daily scrum).

Ensure each scrum member answers the following questions in the daily scrum

• What did they work on since last scrum meeting?
• What are they planning to work until next scrum meeting?
• Are there any issues they would like to highlight?

Try to have daily scrum next to a while board, record what team members are working on today and not what they did yesterday, ask them status about tasks they were working on since last scrum meeting. Make sure that the burn down graph of the sprint is updated, if there are any other status (e.g. Build Status, Regression Test or Bugs reported) update them on the white board for everyone to see.

To be a successful ScrumMaster please ensure the following

• Resolve conflict between team members as soon as possible.
• Ensure everyone is heard and has opportunity to respond.
• Ensure people do not get too much in to the details.
• Daily scrum is to report progress and raise problem (not to solve them in the meeting).
• If the sponsor is attending the meeting they are only listening (they are not allowed to talk).
• The only people allowed to talk are the one who are working in the sprint.
• Normal meeting etiquette is observed.

The most important thing for the ScrumMaster in the daily scrum is to keep track of time, there is no rule (at least that I am aware of) as to how long the daily scrum should last, at our place we have about 12-15 team member and the scrum lasts about 15 minutes, so I would recommend about 1.5-2 minute per person.

Some of things you should watch out and address during daily scrum

• Team member are providing status to the ScrumMaster rather than team.
• Team member don’t look motivated.

Team will not feel passionate to attend the meeting if they feel that ScrumMaster is not interested to listen to them, with that thought I will take your leave until next time... bye for now.

Shorter Release Cycle

Quality of software can be improved over a period of time by introducing shorter release cycle (I am experiencing it first hand at my current workplace). It is a known fact that software has defects, there could be many reason for that, bad requirement, poor coding and not enough testing, fortunately over the last decade or so people are so use to defect they have started accepting it in some form or another.

Defects which are left in the software too long becomes an undocumented feature and when it is fixed you are bound to upset some of the customers.

Introducing shorter release cycles ensure that software gets out of door more often and chances of identifying defect increased, which in turn means more (and timely) opportunity to fix them. This also means that no defect is left long enough to become a feature.

Shorter release cycle also means more excitement to the development team, users and market, it enables team to release new feature in a controlled fashion to get a feel from the market before you invest heavily in any given functionality. It also give you more opportunity to catch up with your competitors.

Releasing web based software could be much easier, fix has to be deployed only once, and is available to everyone instantaneously, but there is also a downside one defect introduced and everyone is affected immediately, frequent release can also upset web users as no one likes to put up with changes every day, but it gives you an excellent platform to change user habit slowly over a period of time.

Releasing software more often can also pose some challenges to the internal team as well as customer, since customer has to upgrade more often it also creates a sense of uncertainty (as they say 'known enemy is better than unknown friend’), but over a period of time team and customer will get use to the release cycle and will start seeing the value. The key is to release software timely without compromising innovation and stability.

On the final note regularity = reliability = happy customers.

Critical Success Factor (CSF)

Critical Success Factor (CSF) are defined based on individual organization’s goal, objective and mission, a good CSF are the ones which can be measured, and when I mean measured I don’t mean by a score, there needs to be a baseline defined for each CSF to be measured against.

One of the CSF for a project I worked for in past was 'ease of use', immediately when I looked at the CSF I told them, that’s an interesting CSF and I posed them a question, how are you planning to measure that?, and guess what I did not get any tangible answer, the reason was that everyone agreed that we want to deliver a software which is easy to use but did not know how to measure it? that does not mean it is not a good CSF. The moral of this story is that if you cannot measure something how you will decide if it was successful or not, sometime we do not have to categorize a CSF as success or failure it could be how effective it was and that’s good enough (at least for me).

One another CSF I came across was 'increase in sales by 20%', which was later changed to 'increase sales by 20% from last year', now this can be measured, do you agree?

Identifying CSF (oops measurable CSF) at the begining of the project is very critical for project's success and for stakeholders confidence in the project.

Some of the typical CSF is as follows

• Solution will be delivered by so and so date.
• Solution needs be able to install via an installer.
• Software needs to be up and running with no (or absolute minimum) configuration.
• Sales order should be placed within X minutes.
• Quotation needs to be generated within X minutes.
• Implementing this solution needs to save X dollars in operational cost.

Sometime there could be different CSF for different team, but an experienced BA will ensure that every teams individual CSF can be used to measure organizational CSF.

It is very important to constantly keep an eye on CSF, the progress needs to be recorded correctly and more important timely, very recently I saw people in my organization using burn down graphs and backlogs, the tool was very simple to maintain and enabled the whole team to act in time and monitor progress, that’s what I like to see.

Bye for now…

How Business Analyst fits in Agile Environment

There is a lot of information and talk these days on agile development, so I am not going to bore you with agile software development principals.

But one thing I hear a lot is that most (if not everyone) in agile environment thinks that there is no need for a BA. Well I am going to be up in their face and say "Mate you are wrong”, there is more need for an experienced BA than ever and I will try to explain why.

Most of the agile project (if not all) gets disconnected from the business stakeholder over its development course and BA forms a very important link to ensure this does not happen.

Since Agile development is very organic and does change its shape and form, BA has to be constantly on their toes to make sure all the changes are well document, discussed and agreed. Since BA has tremendous business knowledge they are in better position to evaluate every option in terms of their business benefit for the business users and in the best interest of the stakeholders.
Some of the questions you can expect from a BA are

• What about this, have you thought of another option?
• Why this option?
• Do we really need this option?
• How does this change the user experience?
• What is the advantage of this option to business users?

BA will also ensure the team is solving a business problem, keep them aligned with stakeholder's goals, with that thought I will take your leave ... see you next time.