Business Analysis
Agile
BA Foundation and Practitioner Course!
Agile Fundamentals
In order to succeed with agile, teams and organizations should focus first on “being agile” as a foundation for success in “doing agile.” Agile fundamentals learning objectives delve into key concepts such as adaptive planning, value-driven development, team collaboration and frequent feedback for continuous improvement. The course also covers the history of agile, the agile manifesto, the agile principles, and some widely applied frameworks and practices. Students come away with a solid understanding of core concepts as they prepare to embark on their agile jo
Agile Business Case
According to the DSDM Agile Project Framework an outline of an Agile Business Case might include a statement of:
●The business vision of success
●The scope and objectives of the proposed project
●High-level assumptions, dependencies and risk that may impact project viability
●Any alternatives that were considered and rejected
●The major deliverables of the proposed project
●High-level costs and benefits of the project
What differs an agile business case from any other business case? It might be that within agile, a business case is an evolutionary product.
Stakeholder Management in Agile
Management of stakeholders is critical element of most projects and it is often neglected or given insufficient attention in both predictive and agile methodologies. Predictive approaches are more difficult to incorporate the changing views of stakeholders as the project proceeds – given the detailed plan that is created at the beginning of the project and the substantial activity needed to evaluate changes and ensure the plan is effectively changed. In agile projects, responding to stakeholders as the project proceeds is at the core of the method but is very difficult to do well.
User Stories / Requirements
The importance of a well understood, prioritised and agreed set of requirements is self-evident. However, the attempt to define a full and detailed set of requirements too early in a project often proves to be counterproductive, restrictive and wasteful. It is not possible to define all of the detailed requirements at the outset of a long project. The business environment changes as time progresses; new requirements and opportunities present themselves. As the project progresses, the team understand more about the business need. Defining detailed requirements too early means either needing to change the specification later, which wastes the original work, or delivering to the originally-specified requirements and subsequently failing to adequately satisfy the business need.
Prioritisation/Workshops/Timeboxing
Have you ever tried speed networking? At these events, you quickly exchange information with a whole lot of potential contacts. When the moderator indicates that each five-minute "meeting" is over, you move on to the next member of the group. If you make a strong connection with someone, you can exchange details and arrange to talk again. By the end of the event, you've likely gained lots of exposure, collected a number of business cards, and laid the foundations for valuable, ongoing relationships, quickly and efficiently. Speed networking is an example of a time-management technique called "timeboxing." Here, you break down projects or daily tasks into set periods of time, which allows you to accomplish more than you would with a less organized schedule.
End to End life cycle of an Agile Project
In order to succeed with agile, teams and organizations should focus first on “being agile” as a foundation for success in “doing agile.” Agile fundamentals learning objectives delve into key concepts such as adaptive planning, value-driven development, team collaboration and frequent feedback for continuous improvement. The course also covers the history of agile, the agile manifesto, the agile principles, and some widely applied frameworks and practices. Students come away with a solid understanding of core concepts as they prepare to embark on their agile journey.
BCS Training
Business Analysis Training
Business Analysis and Practice
The Business Analyst is an agent of change. Business Analysis is a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits. Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. Business analysts work across all levels of an organization and may be involved in everything from defining strategy, to creating the enterprise architecture, to taking a leadership role by defining the goals and requirements for programs and projects or supporting continuous improvement in its technology and processes. We have the specialized knowledge to act as a guide and lead the business through unknown or unmapped territory, to get it to its desired destination. The value of business analysis is in realization of benefits, avoidance of cost, identification of new opportunities, understanding of required capabilities and modeling the organization. Through the effective use of business analysis, we can ensure an organization realizes these benefits, ultimately improving the way they do business.
Requirements Engineering
Requirements engineering is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system. The first use of the term ‘requirements engineering’ was probably in 1979 in a TRW technical report, but the term did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial and establishment of a conference series on requirements engineering. Requirements engineering is often very rigid and engineering focused as it originated from the IEEE world. The focus is clearly on developing engineering specifications for a product and not delivering business value in an environment that must address people, process, and technology. With the rapid adoption of Agile development practices, some industry observers have questioned if requirements engineering is still relevant as it is a process for software engineering, which Agile has mostly replaced. Requirements engineering is primarily focused on building products and does not include many of the other activities involved in business analysis such as business process improvements, building a business case, or delivering business benefits.
Modelling Business Processes
Business process modeling is the graphical representation of a company’s business processes or workflows, as a means of identifying potential improvements. This is usually done through different graphing methods, such as the flowchart, data-flow diagram, etc. BP modeling is used to map 2 different states of the process: As-is, the state of the process as it is right now, without making any changes or improvements, and To-be, the future state, after making the changes or improvements. Business process modeling is usually used interchangeably with business process mapping – and they can be pretty much the same, depending on who you ask. They’re both used to graphically represent processes as a means of identifying potential weaknesses or improvements.
Commercial Awareness
The Cambridge Business English Dictionary defines commercial awareness as, "the knowledge of how businesses make money, what customers want, and what problems there are in a particular area of business." In other words, commercial awareness is an understanding of what your company needs to do to be profitable, be successful, and serve its customers well. With it, you know your organization's core values, biggest competitors, key stakeholders, and current business challenges. You also know the organization's strengths and weaknesses, and you can apply that information to make sensible decisions.