How to know, you are not doing SCRUM?

Scrum is an agile, lightweight process that can be used to manage software development using iterative, incremental practices. Scrum does not dictate which practices must be used and because of this reason at times you will see team deviates from SCRUM standards.

Below are some of the things you might observe to identify that you may not be doing SCRUM

• Sprint is shorter than 2 weeks or longer than a month.
• Sprint does not deliver workable product.
• Estimates and detailed task list are expected at the beginning of a Sprint.
• Most of the progress is measure by amount of tasks completed (instead of tasks remaining) for the Sprint.
• Team is expected to complete specifications before development proceeds.
• There is no testing involved in the Sprint.
• There is very little co-operation within the team.
• Individual are responsible for designing and deliveries.

So are you really doing SCRUM?

What is Sprint Review?

A Sprint review is usually held at the end of the sprint to verify and inspect the deliverables. During the Sprint review, the development team, product owner and scrum master collaborate about what was done in the Sprint. In this meeting, the development team will demonstrate the deliverables to get feedback and confirmation.
Sprint review is a four-hour time-boxed meeting for a standard 4 week sprints.

The Sprint review will include the following:

- The product owner will agree on what items are completed and which ones are not completed
- The development team will demonstrates the deliverables and answers any questions
The development team could also discusses what went well during the Sprint, any problems that were identified during the Sprint and how were they resolved
- The product owner will update the product backlog and present the new items

The Sprint review hence will produce an updated product backlog which will be used for the next Sprint planning meeting.

Five pillars of a great Business Analyst

What makes a good Business Analyst, a great one?

Discover what are the pillars that constitute, support, and transcend a good BA into a great one. We need great Business Analysts to execute projects, change businesses, lead and educate teams, create an atmosphere of trust, and get things done!

In this E-book you will discover and learn:
- The most fundamental aspect of being a Business Analyst and why it is easily missed, by most.
- How the changing social contexts are transforming the way we interact, and what a BA should know?
- What makes you an indispensable emotional worker, as a Business Analyst?
- Key concepts that help you understand each pillar, with real stories and examples
- Action items(we all love these, as BAs) to help you implement and realize the essence of the five pillars

This E-book is available from www.TheBACoach.com.

PROUD TO BE KIWI I.T.

Our vision is about making New Zealand the recognised leader in I.T. innovation and practice.

The Getting I.T. Right Initiative (www.gettingitright.co.nz) is all about how we do this.

Despite some great progress in standards and methodologies, we are still experiencing a very high project failure rate. A conservative measure suggests that collectively we lose in excess of over $1.5 billion each year. Do these scenarios sound familiar? Our experience and research indicates some the following key reasons for project failure:

Lack of Strong Sponsorship and Governance
We have all worked in projects where sponsors were not committed, lack understanding of the project and have not been actively involved in the project strategy and direction. This then impacts on the uptake rate of change and adoption of the change.

Wrong Reasons
Projects are started for the wrong reasons. Some are initiated purely to implement new technology without regard for whether the technology is supportive of the business needs or strategy. The converse of this is a project that does not support existing technology, resulting in major scope creep and resultant expenditure.

Staffing
Not enough dedicated staff (project managers and project team members) allocated to projects. Project team members lack experience and do not have the required qualifications. Line-staff believe that they will be able to succeed in project leading but are only 40% available to do so. Focus in this regard is not on the delivery of the project, but on the comfort zone of the project manager and his own time management. Incomplete project scope. No clear definition of the project's benefits and the deliverables that will produce them.

Part of our plan is educating business owners, directors and executives to work together and to work with the professional bodies and user groups to promote best practice. We can do this through the promotion of this site and with your support we can lobby the correct people and groups, e.g. IOD, MED, Chamber of Commerce, NZCS, etc.

So if you are frustrated with working on projects that dont deliver, that are de-scoped, with customers that are disengaged, and would like to work in a place that I.T. delivery is seen as a vital part of the businesses success, you are given the right tools, your colleagues are enthusiastic and you deliver cool things that make a real difference, then please support this initiative. You can do this by:

Registering your support on the site itself
Becoming a Linkedin member http://www.linkedin.com/groups?about=&gid=3787881

Sharing with Facebook http://www.facebook.com?pages>?Getting-IT-Right-NZ?202191233125814

Following us on Twitter http://www.twitter.com?GetITRightNZ

Marketing Strategy

Marketing strategies serve as the fundamental of plans designed to meet market needs and reach marketing objectives.Your marketing strategy should follow from your assessment of the market. The first thing you will do is to identify the market you are in? How will you address that market? What are the current needs of the market?

Marketing strategy are made up of the following

Product Strategy:
This section should address about your product or services you are offering, what are your specialties for the given market. What makes you different than anyone else offering similar product or services? Make sure you collect all the testimonials of your existing customer.

Pricing Strategy:
This section should address pricing model of your product or services, make sure your pricing model can be used by your smallest customer to the bigger ones.

Advertising Strategy:
This section should address your current business plans for promoting your products or services. How are you going to get your customers attention to your product? Plan your marketing platform, what, how, where and when will you advertise? Do you have a dedicated budget for promotions? What are your promotion strategy for now, 6 months from now and 1 year from now?

Position Strategy:
What is an idea market position for your business and how do you plan make an impression to your existing and new customers, this section also covers branding of your business.

What is the Business Analysis Body of Knowledge (BABOK)?

The Business Analysis Body of Knowledge is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. As with other professions, the body of knowledge is defined and enhanced by the business analysis professionals who apply it. The BABOK describes Business Analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution.

The BABOK provides a basic reference for anyone interested in the profession of Business Analysis. The primary purpose of this guide is to identify the Business Analysis Knowledge Areas that are generally recognized and accepted as good practice. The Guide provides a general overview of each Knowledge Area and the list of activities and tasks associated with each.

The BABOK is intended to describe and define business analysis as a discipline, rather than define the responsibilities of a person with the job title of business analyst. Business analysis may be performed by people with job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others.

Knowledge Areas A knowledge area groups together a related set of tasks and techniques. The Guide to the Business Analysis Body of Knowledge is not a methodology. While it defines the activities, tasks and knowledge that a business analysis professional needs to know, it does not do so from the perspective of prescribing an order or sequence.
Specifically, the knowledge areas do not define a business analysis methodology. They do define what the BA needs to know to work within any analysis process or overall so-utions development methodology. While the flow between tasks and knowledge areas may appear to follow a well-defined and progressive sequence, this structure was primarily developed for pedagogical purposes. In reality, business analysts are likely to find themselves performing tasks in all knowledge areas in rapid succession, iteratively, or, in the case of a requirements workshop, simultaneously!

Business Analysis Planning and Monitoring is the knowledge area that covers how we determine which activities are necessary to perform in order to complete a business analysis effort. It covers identification of stakeholders, selection of business analysis techniques, the process we will use to manage our requirements, and how we assess the progress of the work in order to make necessary changes. Business analysis planning is a key input to the project plan, and the project manager is responsible for organizing and coordinating business analysis activities with the needs of the rest of the project team.

Elicitation describes how we work with stakeholders to find out what their needs are and ensure that we have correctly and completely understood their needs.

Requirements Management and Communication describes how we manage con-flicts, issues and changes and ensure that stakeholders and the project team remain in agreement on the solution scope. Depending on the complexity and methodology of the project, this may require that we manage formal approvals, baseline and track different versions of requirements documents, and trace requirements from origination to implementation.

Enterprise Analysis describes how we take a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. Here we will talk about problem definition and analysis, business case development, feasibility studies, and the definition of a solution scope.

Requirements Analysis describes how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results.

Solution Assessment and Validation covers the role of business analysis once the pro-ject team is ready to propose a solution. It describes how we assess proposed solutions to determine which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution. It also describes how we assess deployed solutions to see how well they met the original need in order to enable businesses to assess the performance and effectiveness of projects.

Underlying Competencies describes the behaviors, knowledge, and other characteristics that support effective business analysis.

How to be a high performing Business Analyst

Being a Business Analyst can be very tiring, you may be juggling more than one project, meeting various stakeholders, managing deadlines all while gathering requirements. There are days where you seem not getting anywhere and have the feeling that you have made no progress whatsoever and haven’t delivered anything tangible. To avoid getting in this situation being productive is very important, after all we all want to achieve more with less effort.
Over the last few years I have performed various activities to increase my productivity and I could share some of them with you.

Make use of all the spare time
There are times where you find yourself waiting in queue or traveling to work these are great time to do something useful, if you use public transport you could take reading material with you and if you drive to work, make sure you load your iPod with podcasts or other training materials.

Use the right moment
Every one of us has the favorite time of the day when we feel very energetic and creative, use those times for analysis or creative thinking.

Be efficient
We all find our self doing some work again and again, like documenting meeting minutes or drawing process diagram, make sure every time you do something new store it in a repository which you could use when you have to perform the same task again.

Delegate
Now this can be hard to some people, as a BA we tend to take more tasks than what we need to, try to delegate the tasks to other team members, I recently found that I nominated someone in my team to be the scribe in the meeting it gave me more time to run the workshop and concentrate on gathering requirements.

Take breaks
It is very important to take regular short break, go for a walk or visit the kitchen, it is an excellent place to meet people and build relationship with your stakeholders and users.

Say NO
I must confess I am not very good at this but there will be times when you have so many things to do, if you take any more work you will not be able to perform well and it is best to say no in those instances.

Tidy your workspace
I know this sound obvious but you will be amazed how great and energetic you will feel when you have a tidy desk.

Involve in Social Activities
To be effective it is very important to balance work with rest, attend the social events at work, find yourself a lunch buddy or even start a book club at work.

Exercise
Staying health is very important to be productive make sure you stay healthy by eating healthy food, exercising and sleep well.

Allocate fixed time for certain tasks
If you find yourself doing certain activities which take forever and before you realize you have already spend more than required time, identify those tasks and before you start them allocate certain time and stop working on it when the time elapsed, you may want to continue working on it after you have completed some other task.

Taking time off work
Make sure you regularly plan your holidays, there is nothing more energetic to take a day off every now and then from the work environment and do something you are interested it, that way when you come back to work you are more focused and rested.

Change Control Board (CCB)

I am sure you have come across this term many times so let us explore what it mean, a Change Control Board (CCB) is a group of people (or committee) whose main responsibility is to make decisions regarding whether or not proposed changes should be implemented. The change control board normally has project sponsor or a representative of the sponsor, product manager, project manager and BA, they may also include representative from each department/division for better visibility in the organization and to take informed decision.

The main purpose of the CCB is to ensure that proper (and agreed) process is followed for every change request; CCB will ensure that an impact analysis is performed and cost of the change is derived which will used to accept or reject the changes.

Depending upon the authority granted to the CCB they may approve the changes or have to go to steering group and/or project sponsor for approval.

CCB may also be responsible for change management and informing affected individuals/departments, if this is the case make sure you choose people who are influential as they can play a very important role in managing and communicating the changes.

Failure is not fatal, but failure to change might be -John Wooden.

5 Whys

5 Whys is a very important techniques a BA could use to determine the root cause of any problem faced by the organization, the critical element to this technique is to challenge the underlying assumptions business has for any given problem, this technique is very simple and works very well in a heterogeneous group setting.

There are basically three steps to conducting a 5 Whys technique:

1. Invite all the stakeholder who are aware and/or affected by the problem.
2. Write down the problem at hand, now ask the first “WHY” question to the group. Why do you think this is happening? Chances are that the group may come up with few answers. Write down all the answers below the question, make sure you do not discard any answers.
3. Now repeat the above step four more times for every answer going one level down, make sure you write the answer below the earlier answer.

This technique does not mandate you to ask the question 5 times, but it is generally believed that it usually takes about 5 levels to get to the root cause of the problem, you may ask less question or more depending upon the problem. Make sure that the current assumptions are challenged and the group does not stop at the symptoms, remember the goal is to find the root cause of the problem so in theory stop asking why only when the group cannot answer any further. Document all the answers in plain English (business language), avoid any technical jargons. As a BA (and moderator) in the meeting make sure that the purpose of the meeting is to learn and improve and not to blame and vent out.

Some of the advantages of this technique are
- Easy to understand by business and technical people alike
- No need of any special tool

Always remember if you do not ask the right question you will never get the right answer. I will leave you with a very interesting and relavant quote.

“Do not look where you fell, but where you slipped.” - African proverb

Power of Acknowledgment

I appreciate acknowledgment every now and then, a good acknowledgement in fact makes my day as long as it is real, sincere and heartfelt.

Now if that makes me happy I am sure that makes others happy too, but how often do we acknowledge people, not very often, it is difficult, we are so verbose when things go wrong but the same enthusiasm is lacking when things go right.

If you acknowledge someone you inspire and motivate them, it is also very crucial for a healthy relationship. Delivering an acknowledgement is an art and if done correctly can be very powerful else it may have an entire opposite effect.

Below are some of the tips on delivering effective acknowledgment

Tip 1: Communicate only when you are happy, your message will be heartfelt and will appear genuine.

Tip 2: Differentiate between Acknowledgement and Compliment. Acknowledgement is about recognizing their accomplishment and to show that what they did has made a great difference. Compliment is just being nice, kind of good manners.

Tip 3: Use facts and examples to support your acknowledgement rather than generic thank you statements.

Tip 4: Be honest, do not acknowledge when you don’t believe in it, most people can see right through and you can actually come across insincere or every phony.

Here are some myths about acknowledgement

Myth 1: Only positive people should be acknowledged. There are always people in team who bring positive criticism; even they need to be acknowledged.

Myth 2: Rare acknowledgement is more precious. In fact the more generous you are with your acknowledgment the better it is.

Myth 3: People are just doing their job. Most people want to go a great job and everyone does a great job but every acknowledgment makes them work harder and feel treasured.

Myth 4: Individuals should not be acknowledged, it is bad for team morale. I some time think the team concept has gone too far, as must as the team delivers but the members within the team are the one who makes it happen. The best strategy is to compliment the team and acknowledge the individuals.

I would like to mention a very recent incident, I was on a flight to Melbourne for a user conference when the air hostess was serving food, she gave me two choice Ham salad or spinach roll. I ordered spinach roll, just before serving me she said ‘Sir I know you ordered spinach roll but I feel I should mention that it has beef in it, will that be ok with you?’. I think she guess that I am a Hindu and don’t eat beef but that comment was so sincere that it touched my heart, I told her ‘Thank you very much for asking, I don’t mind eating beef but thank you for caring”. In fact also wrote a letter to the airline to acknowledge the great service I experienced. I am sure that the air hostess felt happy to receive an acknowledgement but I was happier to give one, in fact giving acknowledgment is a win – win situation.

Practice this skill on daily basis, try to acknowledge at least one person every day, you will see that you create so much positive energy and enthusiasm.

The five ‘P’ in a team formation

Here are the five areas to be discussed when forming a team.

People
I am sure you will agree that this is perhaps the most important area of the team, after all it is the people who makes the team. Success of any team depends upon getting the right balance of people in the team. In an agile environment it is very crucial to create a cross functional team, not just based on their roles and experience but also their personality.
Team is just not about picking the best people from the organization, it is a combination of people to form the best collaboration. Do not hesitate to pick someone who may not be very experienced but that person may be a good team player and will bring the best of people around him/her.

Purpose
No one can guarantee success if the team has no clear purpose. The entire team must be clear on what the purpose of the team are, it is also very important to align the purpose of the team to the vision and goals of the company, this way you always get buy in from the senior managers.

Place
Ensure that the team fits into the organization structure in such a way that it adds value to the company, draw people from various part of the organization to ensure that most of part of the organization are well represented.

Power
Discuss and agree with each team member their responsibility and authority, discuss what the boundaries of the team are?

Plan
Plan is all about the structure of the team, who will do what, when and how? Who is running the team? You may want the team member to decide amongst themselves the detail plan.

These above areas are important to address because they directly affect the team's ability to achieve its goals.

Writing Agile Requirements

Lots of people believe that in agile environment, requirements are not necessary, that is not true at least according to me.

The requirements in agile environment are represented as user stories, user stories helps the team to understand who the actual users are, what they want, what is to be developed and what should it look like when it is completed. The ability to write and understand user stories is the heart of agile development and everyone involve in this environment which includes developers, BA, testers and business users should have or learn this skill.

When writing an agile requirement try to answer the following questions “Who, Why, What and When”. Start with gathering high level user stories to describe the needs and goals of the stakeholders, this will help you to identify project goals and deliverables. Every user story created there onwards should one way or another add value to the high level user stories, the advantage of that process is that if you find any stories which do not contribute to the high level goal you should ask ‘Do we really need this?” or perhaps you have misinterpreted/misunderstood the user story.

For each user stories it is also very important to write the acceptance criteria which usually come from business users. This is very crucial during the QA and UAT phase, do not leave this for later, it is very important and the best time to do this is when user stories are created.

During gathering agile requirement focus more on ‘why’ and ‘what’, do not fall into the trap of ‘how’ which is very tempting especially if you have developers and architect in the meetings.

For each requirement define the scenario broken down by pre-condition, actions and expected behaviours.

All the user stories collected during various meetings will form your product backlog, later based on the prioritisation user stories will be added to the iteration backlog.

The biggest advantage of agile requirements is when you have product managers, business users and developers working together you get the best outcome in the shortest period of time.

Finally don’t be tempted to gather and define all the user stories in advance, all you need is the user stories for the current release, once you get to a stage of implementing a user story that is when more details are needed.

Feel free to contact me if you have any questions, good luck with requirements gathering.

BA involvement in pre-sale support

As a BA you may be called upon to help the sales team with pre-sales support sometimes also called as Request for Proposal (RFP), although it is hard to generalise the content of the document they usually follow a standard format.

Sales people may not have the technical knowledge for the RPF and that is where the BA can be very handy, you may ask a question as to why not involve the technical people? The answer is very simple, most of the RFP are targeted to middle or senior manager and some may have the technical expertise but in my experience most don’t, so there is a need to represent the technical information in a business language.

BA will play a major role in designing and developing a prototype for the proposal, a good BA will spend reasonable time investigating customer’s business, trend and preferences to customize the demonstration that will make the customer more confident on your product/service.

Sales people are often stereotyped as commission hungry and income driven individuals , getting a BA involved in the sale gives customer the confident that your company is serious about the product/service and they are thinking of all the aspect of the sale like installation, implementation, training, support and maintenance.

There is one more advantage in this process, as a BA you experience firsthand the needs of a new customer this can be very handy to enhance the product and may lead to identify new opportunities and business sector.

Requirements Process - Three C Phase

Capture
Make sure you gather and capture as much requirements as possible, do not get too much worried about the format of the document or the structure, the focus should be more on completeness rather than tidiness or presentation. Involve the end-users or customers as much as possible during this phase. Make sure you record all the spoken and unspoken requirements, try to focus on what rather than how.

Clarify
In this phase make sure you clarify the requirement with the SME or users, developing prototype or test cases can help you clarify the requirements, make sure that the requirements are measurable, this phase is very important as it also determined the completeness of the requirement by formally inspecting the documents as a group.

Confirm
In this phase evaluate and agree which requirements will be done first, this phase will help you to remove those high cost but low value features. In this phase project scope will be identified and milestones will be defined.

BA as Innovator

The only way you can survive in today market is by innovating, innovation is not limited to technology and solution, innovation in strategies and business models are also very important, in fact innovation can be performed in any area.

Traditional thinking is that innovation is for creative mind and venture capitalists, I beg to differ, innovation can be performed by anyone and at anytime (in fact every time) in any role they are performing, all you need is the ability to dream.

Innovation is not only about creating new products; innovation is about reinventing business process, venturing into new market and meet untapped customer’s need. Innovation may be high in small size companies, partly because it is the only way to survive against the big companies, but I have seen innovation in large companies too like Google, it all comes down to company culture and how much do they promote innovation.
The first thing which pops in my mind about innovation is iPod, they were not the first player in the market, but they are popular because of the innovation in their business model, simple interface and the online music shop, they added the WOW factor to the MP3 player, they recognized and tapped the customer trend and fashion.

The first step to be innovative is to remove the fear of failure, take risks and embrace failure, don’t spend too much time taking decisions, all the good ideas seems meaningless and impossible initially. Try looking at other industry to get inspiration, there is nothing like bad ideas, there may be ideas which are not feasible but that’s life.

As a BA you are in a perfect environment to be innovative, most of us are responsible to implement an innovative idea but does that mean innovation stops there?, you can use innovation to implement the idea (which include software and process ). Be a bit more social, try and meet BAs from other industry talk to them to find out what they are working on, learn from their success (and their failures).

Try getting in the head of your target audience, try to see what customer sees (or expects) which you have missed, walk a mile with them, feel their pain and frustration, a small change in the way you do things can make a big difference in their life, the moment a customer thinks they are being heard, they will be more open with suggestion and criticism.

These days business are getting global in nature, do not restrict yourself to a particular region, sooner or later you will venture out and you need to think (NOW) about the opportunities you can tap in future. Sometime to be innovative you have to go to the opposite direction from where your industry is going, you'll redefine the rules of the game.

Thank you very much for reading and don’t forget to dream.

Vendor Assessment (Part 3 - Technology and Commercial)

In my previous post I spoke about how to assess vendor on software development criteria, this post I will continue the discussion

Technology

Platform

• Is the Software developed as per company hardware requirements?
• Software developed in accordance to company software requirements?

Coding Standards

• Coding standards followed based on company coding standards?

Comment in Code

• Will all classes, functions, procedures be documented ?
• Will comments be used to describe intentions, algorithmic overviews, and/or logical flows?

Documentation

• What code documentation and end user documentation is provided ?
• Data Model ?
• Class overview ?
• Architecture overview ?

Training / Handover

• Is there a proper procedure for handover and time allotted for training?

Commercial

Development Cost

• Is the proposed development cost acceptable?

Delivery time

• Is the proposed delivery time acceptable?

Support Cost (e.g. training, end user support if required, technical support)

• Is there any support cost involved?
• Is there a warranty period suggested?

Maintenance Cost (i.e. bug fixes)

• Is there any maintenance cost involved?
• Is there any warranty period suggested?

Terms of Payment

• Are the Terms of payment proposed agreed by the sponsor?

Penalty / Incentive

• Is there any penalty proposed if the milestones are not achieved on time?
• Is there any incentive available to achieve before time?

Ownership

• Is the company claiming any ownership on the software developed?
• Are the any licensing fees involved?
• Do they intend to use this product for any future development for their clients?

The list goes on, I do not intend to blog every criteria but the list above could be a good start, do not hesitate to contact me with your feedback.

Vendor Assessment (Part 2 - Software Development)

In my previous post I spoke about how to assess vendor on company background criteria, this post I will continue the discussion

Software Development

Project Management

• Will a proper project manager is assigned to ensure smooth running of the project?
• Does your company recommended any project management methodology to be used?

Project Status Update

• Are regular project status update provided? Will it be targeted to shareholder and sponsor?

Development Methodology

• Are development methodology used is in accordance with your company's development methodology.
• Is the proposed methodology compatible with methodology used currently within your company?

Regular update and enhancement

• Are regular update and enhancement in the future if required?

Milestones

• What are the milestones, are the proposed milestones acceptable?

Issues/Bug Management

• Is there a proper process/tools proposed to handle bug and other issues raised during and after QA and UAT process.
• What is the proposed turnaround time to action/resolve the queries raised by business users? are those time frame acceptable?

SLA (Service Level Agreement)

• Is the SLA proposed by the development acceptable?

Functionality

• Is the functionality in the Requirements document included?
• If the software is extending current functionality, How will they ensure the current system functionality is retained?

In my next post I will continue talking about technology criteria.

Vendor Assessment (Part 1 - Company Background)

In your BA life every now and then you are faced with a decision whether to develop the product in-house or outsource it. I am not going to discuss the in-house- VS outsource in this blog, I am assuming you have come to conclusion with the stakeholders that you are going to outsource the development and that when the main question comes in as to who should we outsource to?.

Outsourcing development is a major investment for any company and requires careful and complete evaluation of the quotes received from the various software development companies.

Start by separating the “must have" criteria from the "would like" criteria. Proposals that do not meet all of the "must have" conditions should not be evaluated further. The final recommendation should be then made via a weighted assessment of the proposals.

Company Background

The first Impression

• Did the company get back to you on time?
• Were the people dealing with you were professional?
• Did the company’s representative asked any questions?
• Did the company’s representative understand the requirement

Total Employees

• These criteria will determine the resource available to execute and maintain the project.

Experience and References

• Experiences will determine if the company has developed a similar project, this is reducing the learning curve and increasing the quality of the product delivered.
• References will be used to determine if the earlier project they executed were delivered on time, as expected and within cost.

Stability

• How long has the company been in business
• Will the company be in business in five years?
• Good market standing

Customer service

• These criteria will ensure we are dealing with a professional company.

In my next post I will continue talking about software development criteria.

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.