Nowadays organizations move toward development ,agility and project management teams are still struggling to define the common language and standard regarding the agile framework. Many organizations that are implementing agile methods , have not fully planned the transition and are still unclear on how to fully optimize or utilize the approach. One area that continues to remain uncertain is the role of the business analyst (BA). Below we are considering some steps to help business analysts to navigate their way through the transition to agile and add the most value to their agile teams.
Understanding the agile Mindset
Agile Manifesto
Any business analyst (BA) practicing in an agile environment must first have a basic understanding of the agile mindset and know about why it was established. The Agile Extension of the BABOK v3.0 Guide describes the Agile as a mindset that guides the way of work is approached. Key characteristics of the agile mindset include rapid delivery, increased collaboration, empirical learning, avoiding waste, and producing high-quality products.
12 principles behind the Agile Manifesto are as follows :
To learn the concepts of the Agile Manifesto, agile business analysis practitioners also recognize the 12 Principles behind the Agile Manifesto. Understanding these principles will help the agile team members, determine how to facilitate many interactions involved in the software and project management. This is especially important in maintaining the overall essences of the frameworks. Less rule-based approach can often be misconstrued , if the founding principles are not emphasized .
Understanding the Agile frameworks
There is another key component of the agile business analysis to understanding the term Agile is a high-level framework with various defined frameworks that fall underneath. Some of the most frequently used agile brands include Scrum (most common agile framework),Feature Driven Development (FDD), Kanban, eXtreme Programming (XP) , Scrumban,Crystal Methods, Large Scale Scrum (LeSS) , Dynamic System Development Method (DSDM) and many others. It is important to learn about the various agile frameworks because the organizations need to assess the frameworks and employ the one (or combination) that best aligns with the organization. While there will certainly be shifts in the organizational operations and the culture during the transition to an agile environment, choosing the framework that complement the existing environment may ease the process.
From the business analyst perspective, the learning and the roles and the responsibilities within these frameworks will assist in setting the proper expectation for the new roles or responsibilities. It will also help to understand the intended value of the various ceremonies of the framework. The business analyst role is not distinguished in some agile frameworks; therefore it is essential for the business analysts to understand where their skill set fits, so they are able to add as much value as possible to them.
T-Shaped Learning
Cross-functional teams
In most agile frameworks variations of three key roles are recognized, which are Team facilitator,Product Owner, and Cross-functional Team Members. BAs in an agile environment typically fall into the cross-functional team member role. In order for the business analyst to be successful as a cross-functional team member, he /she must accept a T-Shaped learning environment. This type of environment encourages the team members to be cross trained in multiple areas. Members add values because they have deep knowledge in one area supplemented by high-level knowledge in a broad range of other areas. This provides the flexibility for team members to pick up work throughout the entire software development life cycle as well as shift work to the highest priority tasks when needed.
Business analysts on agile teams who feel underutilized or Wasted and not used well will need to discuss the issue with the team facilitator to determine what additional skills can be picked up to add more values to the team. Most cross-functional team members are composed of business analysts,testers, and developers.
The figure given below illustrated the T-shaped learning model for a cross-functional agile team:
-
- Train other team members on agile business analysis activities such as storyboarding,developing personas, writing user stories, story decomposition,defining acceptance criteria, and wireframing.
- Learning skills outside of the core business analyst skill set such as QuaListItemty Assurance testing and coding
- FaciListItemtate planning horizons
- FaciListItemtate collaborative eListItemcitation workshops
BA-Product Owner Relationship
Many business analysts have found that Product Owners (PO) have assumed that many of the traditional BA responsibilities. There is another area where the business analyst skill set can add other significant values. Many product owners (PO) are appointed because of their significant business knowledge, however if not formally trained, many of them lack the project related skills to be fully effective. Team members with a business analyst background will need to train and support the Product Owner (PO) on tasks such as developing business cases, writing user stories, cost/benefit analysis and writing test cases. Some business analysts (BAs) in agile environments have even transitioned to the product owner (PO) role, however it is generally best to keep the two roles separate. One thing to note about the business analyst role is that in agile is that even though the BA title is marginalized, the BA skill set is emphasized. This means that the skills set and responsibilities of the traditional business analyst are distributed to many different roles on the agile team. Agile business analysis practitioners will need to become comfortable with the fact that requirement elicitation activities will no longer be the sole responsibility of the business analyst, and the other team members will need to be trusted with these tasks as well.
Agile Requirements Management
Less formal documentation
In agile environments, working software is valued over comprehensive documentation. Contrary to popular belief, this does NOT mean that requirements don’t need to be documented. However, this does mean that the requirements are often less formal. Many agile frameworks manage requirements in the form of product backlogs. Here, the requirements are usually represented in the form of user stories with acceptance criteria. The business analyst may need to support other team members to ensure that the user stories are usable and that there is a sufficient amount of acceptance criteria to size of the story and move it into the upcoming iteration. In addition, the stories in the backlog must be prioritized based on value to the business. While the product owner is generally responsible for the priority of the stories, the BAs can add values by assisting the Product Owner (PO) to determine the value (cost/benefit) of each story. An agile business analyst may also be a great resource to the (PO) product owner, when determining the MVP (minimum viable product) for the project.
Working Software
Due to the fact that agile software development emphasizes elicitation through working software, it would behoove the agile business analyst to sharpen up on wireframe and prototyping tools in an effort to quickly obtain rich feedback from the customers. In addition to obtaining feedback quickly, business analysis in the agile environments involves adapting to a flexible scope. While there is some level of scoping in an agile business analysis, the scope of the solution may change as a new information is discovered or the organization’s priorities change. This requires an agile BA to be flexible enough to quickly course correct, re-prioritize, and elicit new information based on what was learned from customer feedback.
Agile BA Techniques
Agile business analysis practitioners many need to expand their business analysis toolkit to include the techniques that are more suitable for an agile environment. Agile business analysis techniques are less focused on research and more focused on the experiments and the collaboration. Agile BA techniques facilitate knowledge transfers between different planning horizons (Strategy,Delivery,and Initiative), where the feedback obtained in one horizon provides direction to another horizon before moving forward.
-
- Acceptance Criteria – Used to support the user stories to determine when the story is complete and will achieve user acceptance.
- Backlog Management and Refinement – ListItemst of stories prioritized by the value-added to the business or urgency in deployment. Backlog may be refined in an effort to ensure that the stories meet the team’s definition of ready prior to being moved into the next iteration for work.
- Behavior Driven Development – Focuses on customer behavior for the solution to address a customer’s need.
- Job Stories – Used to represent PBI (product backlog items) that describe what a stakeholder needs and the motivation for that need. Job stories focus on the value to the customers, while user stories focus on the features that address a need.
- Kano Analysis – Used to display the customer’s view of product features and determine those that are most significant. Product features are identified as one of the following categories: threshold (basic), performance, excitement or indifference.
- Minimal Viable Product – The Assesses and prioritizes features/stories to determine the minimum set of requirements that can be deListItemvered, to satisfy the business need in the shortest time.
- Personas – It’s Creates that customer archetypes to provide additional context to the aListItemgn the solution to the customer needs.
- Product Roadmap – Documents and communicates the strategic vision and direction of a product or project as well as to measure the progress towards that vision.
- Real Options – Used to determine the last responsible moment of a decision can be made so that the team can focus on the highest priority issues.
- Relative Estimation – Uses previous experience to estimate the size,complexity, and uncertainty of stories and items in the backlog.
- Retrospectives – The Lessons learned session at the end of each iteration to continuously improve and learn .
- Reviews – The Demonstrations of work completed during an iteration or increment in order to obtain the feedback from the stakeholders.
- Spikes – Used to time-box research-based tasks or effort of a backlog item or prototyping in an effort to determine the complexity.
- Story Mapping – Provides a visual of the priority and the sequence of stories that support a product or a solution as well as communicate the functionaListItemty.
- User Stories – The Statement of functionaListItemty needed to provide values. Written in the voice of the customer. The format includes a role/persona, necessary action, and business value.
Value Stream Mapping – The Facts-based representation of the activities required to deliver a product to the customer. Analyzed in the current state to identify opportunities for improvement and to define in the future state to describe what the process will look like once improvements are implemented.
Conclusion
In conclusion, the role of the business analyst in an agile environment is still vague to many organizations. This is partially due to the fact that the Business Analyst role is not distinguished in many of the branded Agile frameworks. This does not mean that the business analyst is not valued in agile environments. As many organizations are finding, the business analyst skill set is even more critical in agile environments due to changing scopes and priorities, therefore, agile business analysis practitioners must be ready to step up to the challenge. So MCAL Global provides you the best business analyst course name as Master Business Analysis Training in pune and mumbai , MCAL Global has amazing Training activities, so register yourself and get the best Master Business Analysis Training and trained yourself in an Agile Business Analyst. ALL THE BEST .