Skip to content


Waterfal vs. Agile – When is constant communication important on a project?

Waterfall vs. Agile – When is constant communication important on a project?

 

 

 

 

 

Unlike Waterfall, an important aspect of Agile is constant communication between the product owner and the team. Constant communication can reduce wait time for sending and receiving information, improve the quality of your requirements backlog, and can reduce misunderstand between what is delivered and what is required.

Constant communication adds value to a project:

  • When you do not have all the business needs identified.
  • When you are on a tight schedule and require information ASAP.
  • If the product owner/client updates requirements frequently.
  • When you want to avoid delays in sending and receiving key information.

Scenarios using Waterfall:

  • I receive a recurring monthly request to update product prices on a sales database.
  • I create a website for a client; I use a standard template and add client specific information.

Scenarios using Agile:

  • I receive a request to update information on a sales database; updates are required to be rolled out over a series of weeks, and my team is not static, so I need to schedule resources based on availability per week.
  • I am creating a website for a client; they want custom features added; they have a limited budget and unable to add everything they want, and they need to determine what features to use (offer the most value).

Posted in Agile, Business Analyst, Methodologies, Waterfall.

Tagged with .


What does a BA do?

I am often asked, “What does a Business Analyst do?”

Saying “we help business do better business” doesn’t really describe our role.

A BA can perform a wide range of tasks from day to day, project to project, and even from business to business:

  1. Identify and separate the categories of requirements categories;
  2. Determine the correct templates to use for a project;
  3. Define/refine the checklist of requirements activities, deliverables, and schedule;
  4. Create a defect checklist for all templates that lists common requirements errors;
  5. Determine assumptions and constraints;
  6. Help peers check to determine if the requirements are high quality and complete in breadth;
  7. Document all requirements-related terms, enterprise acronyms, and business domain language in an appendix to the requirements document or in a separate glossary;
  8. Assemble and educate the core requirements team, composed of key business and technical stakeholders;
  9. Gain an understanding of the needs and environments of customers, users, and stakeholders;
  10. Review or create if non-existent, the business case, project charter or similar scope definition document;
  11. Examine the business case for a list of business drivers; continually link project work to the expected benefits outlined in the business case;
  12. Understand the business vision, drivers, goals and objectives for the new/changed system;
  13. Understand and further document the scope of the project;
  14. Define the deliverables and models to be produced and begin to develop the requirements management plan;
  15. Plan for change throughout the life cycle;
  16. Customize the project complexity model to the project environment;
  17. Collaboratively determine the size/risk of the project and establish plans accordingly with the project manager and key business technology experts;
  18. Bridge the gap between the project team and the stakeholders by building creative partnerships, conducting voice-of-the-business surveys, and securing customer input by creating focus groups, business panels, and cross-functional decision teams;
  19. Explain the business value expected from the project to all stakeholders to regularly confirm the primary needs that are driving the project;
  20. Develop or refine stakeholder analysis before beginning elicitation activities;
  21. Use the stakeholder analysis to determine and manage early requirements-related tasks;
  22. Identify a champion for each user group;
  23. Make the user champion a key member of the requirements elicitation team;
  24. Establish and document ground rules for making requirements decisions and resolving conflicts;
  25. Enlist the project manager and the business and technical leads to determine the project life cycle and delivery approach to be used for the project; and
  26. Tailor and customize the requirements activities, deliverables, and reviews based on the needs of the project with everyone involved.
  27. Plus much much more…

Posted in Business Analyst, Checklist.


Nominal Group Technique

The Nominal Group Technique (NGT) is an advanced form of brainstorming involving five steps.

Step 1. The BA describes a problem or opportunity to all team members.

Step 2. Each team member separately records his or her ideas.

  • At this point, there is no discussion among group members.
  • This strategy promotes free and open thinking unimpeded by judgmental comments or peer pressure.

Step 3. The ideas of individual members are made public by asking each member to share one idea with the group.

  • Ideas are displayed for all team members to see.
  • The process is repeated until all ideas have been presented.
  • Every idea is assigned a unique number.
  • There is no group discussion during this step.
  • Taking the ideas one at a time ensures a mix of recorded ideas, making it more difficult for members to recall what ideas belong to which individual.

Step 4. Ideas are clarified to ensure that all team members understand each item.

  • A team member may be asked to explain an idea
  • No comments, justifications, or judgments are made in this step.
  • The goal of this step is to ensure that all items are clearly defined.

Step 5. The team will vote on each Idea silently.

  • The team will select method of voting.
    • Example: Team members will select their top five ideas by number.
  • Each member prioritizes his or her preferred ideas and arranges them from 1 (worst) to 5 (best).
  • Results are collected.
  • The priority values are tallied and displayed.
  • The ideas with the highest values are selected as the best ideas to implement.
    • The number of items to implement is determined by time, money, and resources available.

Posted in Techniques.

Tagged with , .


Quality Circles – A tool for improving quality

Improving quality is critical for improving processes, products and services, and increasing stakeholder satisfaction.

A Quality Circle is a group of employees that regularly meets  for the purpose of identifying, recommending, and making process and quality improvements. The Quality Circle will assign a team leader who acts as a facilitator. The facilitator can be a different group member at each meeting. The group may use brainstorming, Nominal Group Technique, or other group techniques; however, Quality Circles discuss their work, anticipate problems, propose workplace improvements, set goals, and make plans. The can meet daily, weekly, or before, during, and after a project to implement and monitor quality improvement initiatives.

Posted in Tools.

Tagged with , .





Warning: mysql_query(): No such file or directory in /home/spydermug/theitba.com/wp-content/plugins/quickstats/quickstats.php on line 345

Warning: mysql_query(): A link to the server could not be established in /home/spydermug/theitba.com/wp-content/plugins/quickstats/quickstats.php on line 345

Warning: mysql_query(): No such file or directory in /home/spydermug/theitba.com/wp-content/plugins/quickstats/quickstats.php on line 346

Warning: mysql_query(): A link to the server could not be established in /home/spydermug/theitba.com/wp-content/plugins/quickstats/quickstats.php on line 346

Warning: mysql_fetch_row() expects parameter 1 to be resource, boolean given in /home/spydermug/theitba.com/wp-content/plugins/quickstats/quickstats.php on line 346