Sunday, November 29, 2009
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)
Tuesday, October 27, 2009
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.
Thursday, September 17, 2009
Critical appraisal is the done at the end of designing phase, the main purpose of this task is to do a final check between proposed solution and physical design, this task along with solution walkthrough gives the stakeholder and the team a common understanding and also the opportunity to identify any missing requirement and most importantly to validate the proposed solution.
The following people (or group) should be attending this meetings
- Business Analysts
- Stakeholders and SMEs
- Business Users
- Development Team
Some of the advantages of this process are
- Confirming the Business Requirement.
- Confirming the physical design.
- Improve stakeholder’s confidence in the project.
- Identify any people or organization problems.
- Identify any function or data problems.
- Identify any performance or workflow issues.
The main topic in this process is to match logical and physical design, if there are data models created, make sure the domain is complete, there are no duplication or redundant data, identify any relationship problems.
The final question BA should ask the team is ‘Does the proposed system meet the organization goals?’. Always remember it is easier to change the design and solution on paper than to change few hundred lines of code.
Monday, August 31, 2009
- Effect/Risk of the problem
- Costs and Benefits
- Financial (expense and revenue)
- Corporate commitment
- Customer pressure/satisfaction
- Industry pressure
- Legal compliance
- 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?
Thursday, August 20, 2009
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.
Thursday, August 6, 2009
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.
Thursday, July 30, 2009
Thursday, July 23, 2009
While doing my Business Analysis I have found that negotiation skills are very important and very crucial part of your role. As a BA you need to master the art of negotiation, you will have to use that skill at various stage of the project, you negotiate with the sponsor with the scope and delivery dates of the project, you negotiate with the project manager to get appropriate resource and on time, you negotiate with the development team with the features to be development and if you are lucky to get this far, you now negotiate with the QA team to ship software with least number of defects.
One thing you have to learn and believe as a BA is that nothing is set in rock, you can and you should negotiate at every possible stage of the project to achieve the best outcome possible.
Some people are natural at negotiation whereas other people need to improve on it, most people see negotiation as negative and tend to avoid it, but it is not about doing the least possible or being difficult, it is about making sure all the party involve are happy, and everyone gets something out of it.
You should be very careful when negotiating, your body language, your tone and your approach is very important. Try to put yourself in other person's shoe that will help you to understand the other person's view, treat everyone as you would like to be treated.
Before you start negotiation sit down and list of following things
- Make a list of every single topic to be negotiated.
- Make a list of topics which should be avoided during the negotiation.
- What are your needs (and not your wants)?
- What is the minimum you want to settle for?
- How far are you prepared to go?
- What is available or possible?
Knowledge is power so make sure you know as much as possible about the thing you are about to negotiate, ask around if anyone else has done it before and what was the outcome, don’t let the other party blind you with technical details, stay focused.
Always remember 'Relationship before task', spend some time with other party to understand their need, always empathise with their problem, avoid and deal with conflict as soon as possible. Always explain to other party why and what are you negotiation for.
Negotiation is not about 'YOU' or 'ME', it is about 'US', be flexible, do not try to drive too hard, make everyone involved feel like a winner.
How do you know that your negotiation was successful?
Well there is no great answer for this but if both parties seem happy with the outcome, which fits into the project goals, I will say that’s good.
In the end don’t forget, negotiation is truly an art and not science, negotiation skill can be improved even in your day to day life activity (some time you are doing it without realising it) like negotiating for a mortgage, car or even insurance. All the best.
Thursday, July 16, 2009
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?
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.
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.
Thursday, July 9, 2009
I come from a technical background, but not all business analysts comes from programming or technical background, I feel both categories of BA have advantages and disadvantages, especially when you are working for a software company.
Let me stick to the topic and focus on BA with technical background, I feel when you start the requirements document it should be entirely based on business outcome and you should not think about the solution or any other technical details, this ensures that your document covers all the business needs and is not compromised by technical limitations.
If your company promotes and allows JAD (Joint Application Development), then you will have to talk to the technical team, I found it very handy if you are able to talk the technical language, but getting too much technical could risk the business focus. On the other hand based on my experience technical team are a bit reluctant to document technical details in that case documenting technical information can be very handy (QA team will thank you for that).
Personally I would rather focus on defining requirements clearly and free from ambiguity then worry about technical details, but BA needs to understand the design concept, in past I have experimented with semi technical document by adding Workflows, UI, Data Modelling and sometime ERD diagrams, that has worked in some cases some and some cases it did not, you will have to use your judgement as to how far you need to go on the technical side, it may also depend upon your audience, too much technical details makes it difficult for a business user to review,understand and verify the requirements.
There is also some overlapping between functional and technical, what is technical to BA is functional to the development team, BA usually have to write functional and non functional requirements so sometime there is no way out but to write technical details.
So in short depending on the willingness, skills and experience, BAs can choose to be more on the technical side or stay focused on the business side, a balance of both side is what I will recommend.
Thursday, June 25, 2009
I think companies should have release team where there is more than one person to manage the release cycle (now of course that depends upon how big is the release cycle and how often it is done).
Software release can be very complex, may involve many small projects, to coordinate, scope of the project can change based on available resource and customer priorities, the main role of the release team is to ensure that the software being released meets customer requirement, all small project are included, and the most important thing is to release on time with highest quality possible.
The software release team should be decided earlier on the project and each person should have a clear responsibility within the release cycle. Often QA team leader or project manager is the best person to be the team leader of software release team. Software release team leader should be expert on interdependencies and various integration issues, s/he should be very familiar with the product to be able to analyse the impact of release on each and every customer, this information is very crucial when the software has to be released with known bugs (I know no one accepts this but it has been the fact of software release)
Some of the role/things to be managed by the release team are as follows
- Who is the Build Master (ideally there should be one complete build every day)?
- Who is responsible for the installer?
- Who is responsible for releasing the software and ensuring the software is delivered to the customers?
- Who is in charge of the release/installation document?
If all (or most of the above) is planned and executed there may not be any surprises on the release dates.
Monday, June 15, 2009
Even in an organization where this is a QA team, often quality starts and finishes with them, I feel quality is responsibility of the entire team, which includes management and BAs, and of course developers. Try looking at your development cost and chances are that 60% of the development resource is spent on identifying and fixing defects. By not introducing defects in the system and implementing proper tools and procedure to identify them earlier on, development cost can be reduced and eventually increases team productivity.
Quality should be enforced right from the beginning of the project (yes even in requirement gathering phase), project leader should focus more on quality rather than quick delivery.
To conclude this blog, there are various level of quality required for software, some mission critical software needs to have close to 0% defect, where as some software can handle more. Quality is an ongoing process, which should be built in to the SDLC, quality should not be looked as burden and requires commitment right from the top level management. Any testing tool can identify the defect but only the ones which falls under the testing criteria, most software are so complex (at least the ones I have worked with) that there is no way you can test the complete software, in this scenario implementing good quality business process (along with testing tool) is the way to go.
Sunday, May 24, 2009
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.
Wednesday, April 15, 2009
Performing a walkthrough process is very critical during analyzing phase, it helps the stakeholder, business user and development team to understand the proposed solution and identify any potential shortfall.
Walkthrough should not be just conducted before the beginning of development; it should be done regularly (as and when needed) during the entire lifecycle of the project.
Some benefits of structured walkthrough are as follows
- Helps stakeholder to believe and take ownership of the project.
- Business users can visualize the solution and propose any changes or highlight any potential problems.
- Reduces ambiguities and identify missing functions earlier on the project.
- Helps the team agree on objectives of the proposed solution.
- Validates the current and complete understanding of the analyst(s).
Planning and Organizing Walkthrough
Make sure that relevant people (preferably one person from each department and/or level) attend the walkthrough meetings, keep the meetings short and distribute material to every participant before they attend the meetings.
Facilitating a Walkthrough
Rules observed during any business meeting should be followed during a walkthrough meeting, such as
- Make sure you book the meeting room well in advance.
- Setup the meeting room before the meeting starts.
- Arrive on time, and most importantly finish on time.
Below are some more tips when you are facilitating walkthrough meetings
- Give every participant a fair chance and time to speak.
- Do not interrupt when someone is talking and don’t let anyone else do that.
- Use terminologies which are familiar to the group and/or organization.
- Take notes of all the proposals, questions and problems identified during the meeting.
- Try to stay away from fixing any problem and/or bugs identified during the meeting.
- Nominate yourself or someone else to resolve any conflicts arises during the meeting.
Always remember the cost of fixing and/or changing anything after the development is complete is very expensive and time consuming when compared to identifying it early on the project. Please let me know if you have any questions and/or comments.
Sunday, April 5, 2009
The main part of the presentation is content, if the content is right and catered for the audience, you are guaranteed a great turnout. You have to make sure that you have done enough research on the topic well in advance, you never know who is going to ask you a question and about what.
One of the thing which is very important in a presentation is to keep in charge, there will be occasion when someone will ask a question which is unrelated to the presentation or perhaps out of scope, in that situation you have to gracefully acknowledge that question and inform the person that you will address that question outside the presentation.
If you know the audience before the presentation it is a very good idea to send them the agenda of the presentation in that way you are absolutely sure you get right people and gives others a chance to gracefully opt out of the presentation.
I think visuals are great in presentation, make sure they are not very small and do not contain lots of information, it can be very distracting for the audience, you don’t want people to lose focus while you are talking.
Make sure the slides are in logical order; there is nothing worse than having to jump from one section (or slide) to another.
Font size should be appropriate, it may be useful to actually project you presentation before your meeting, sometimes text looks quite different on a computer screen then projector screen. Avoid writing text in presentation exactly what you are going to speak. I have attended some presentation where the presenter is just reading the slides; you can have bullet points to highlight items you are going to talk about in your presentation.
It may be very handy to print slides and give it to the audience, in that way they can refer to previous slides and write notes on it, also very handy for latecomers or people leaving early. One more reason is that some people take it with them and keep it for their future use (you may want to email your presentation to everyone who attended the presentation), on that note it may be good idea to mentally record names of people attending the presentation (this may not work if you have a very big audience).
Make sure you do not spend too much time (or too little time) on each slide; my guideline will be about 2 slides per minute.
The most important part of the presentation is YOU, make sure you stand straight, don’t move from one side to another, use less hand movements and the most important thing is your tone, don’t use same tone throughout the presentation (it may sound like a robot and puts people to sleep), show some emotions in your voice, if you show that you are passionate about what you are presenting your audience will feel the same. Practice some breathing techniques; a few deep breaths can reduce the tension and helps relaxing.
Below are some of the things I would discourage you from using in a presentation
- Sarcastic comments on product/people/team etc
- Animated text
- Multi color text
- Share joke (very unprofessional)
- Black (or dark) background
In the end of the presentation, you may want to open the floor for questions and answers, make sure you thank everyone attending the presentation, give your contact details and ask them to be in touch if they have any questions and/or feedbacks.
If you follow the tips mentioned above I am sure you will give a great presentation... all the best.
Sunday, March 29, 2009
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…
So I am going to talk about what team really means (to me), for me "team is a group of likeminded people thinking, analyzing and working together for a mutual goal". Most companies (no offence) think a team is a bunch of people thrown together in a room to complete a task. Now you may argue what is the difference, the difference is more of philosophical, when a group consists of people who have different view and different goal; often it is difficult to increase the productivity and delivery of the group. Why do you think these "Team Building Programme" are getting popular, that’s because more and more companies realizing the true meaning of a team (a good team).
Following are some signs of a good team
- One team member supporting other team member (or group of member).
- Tolerant to each other’s short come, uniqueness and opinion.
- Team Leads are passionate to teach and help team members.
- Team member are open to share their expertise & insight to other team members.
- Team member often stop to see how other team members are doing.
- Team member treat each other with respect.
Something to think eh?
Thursday, March 26, 2009
Now you may think that this is some new cool technology but you will be surprise to hear that BI existed since late 1950s in one form or another.
BA are very integral part of creating BI, interacting with customer, identifying reports, analyzing data, this information can then be applied to the BI, it does not make sense to apply rules to data if you don’t understand the data.
There is one thing everyone needs to understand that BI are great for reading data, massaging data and applying decision and generally does all this very fast, but one thing they lack which is "thinking" (until they perfect artificial intelligence of course), for now BA will do the thinking.
Wednesday, March 25, 2009
Well as much as the title suggest that I am going to talk about who is important over the other, let me settle this before I talk more, the answer is very simple (and you know it) "Both". Now that it is settled I can relax and continue, BA and PM and like two side of coins, depending upon which angle you are looking from, one may seem more important than other, but in reality the only way to guarantee success of any project (big or small) is to have a very experienced PM and experienced BA.
In a project BA manges business stakeholders and PM manages resources (hardware, people, cost), it is very crucial for the success of a project that both role are clearly defined and planned for (unfortunately sometime BA are expected to do both ... but that is a different story).
In the beginning of the project both roles will overlap to define and agree scope, mission, objective, risk (along with mitigation plan) of the project (sometime called "Terms of Reference"), but as the project moves on the roles gets it real shape and each focus on their particular responsibilities and tasks.
It is very crucial for the success of the project that both role are working towards an agreed goal and never lose in touch with the business stakeholders and business users.
Some of the tasks performed by BA are as follows
- Bridge between business users and technical teams.
- Knows (or in the process of) the business in and out.
- Regularly feeds progress back to business stakeholders.
- Resolve conflicts and implement change management process.
Some of the tasks performed by PM are as follows
- Manage resource (people, computer and much more)
- Create a proper (detailed) plan of the project.
- Motivate the team members and resolve any conflict as arises.
- Document change request.
- Keep an eye on the risk and take timely approach to resolve it.
Now as you must have guess that sometimes it seems that BA and PM have conflicting goals, for PM it’s more important to deliver project on time and within budget, for BA it is more important that the business outcomes are achieved, I personally like that kind of tension and that’s where experience comes in.
Bye for now...
Business Analyst is a bridge between technology and business, the one who can see and understand both sides, to support business procedure which in turn increases revenue and decreases operating costs.
An experienced BA will involve business users and technical people from the very beginning of the project; this ensures that both side gets an opportunity to express their views and contribute ideas, this process is called JAD (Joint Application Development). There are various tools which can be used during the various stages of projects some of them are
- Process Mapping
- Data Modeling
- B5 Matrix
- Design Sessions