Agile business analyst

From Pearl Language
Revision as of 07:00, 11 September 2012 by Martien (talk | contribs) (Added job description)
Jump to navigation Jump to search

Business Analysts are well positioned to become critical to the success of Agile teams.

Key for the agile business analyst are:

  • Facilitator skills
  • Coaching skills

For Business Analysts (BA), successfully managing an agile product development depends on defining requirements in smaller increments and working more collaboratively with the development team through the complete lifecycle of a product. agile business analyst are an integrated part of the product team throughout the life cycle of the product and facilitate collaboration across a broader cross section of the product team and the business.

Collaboration, facilitation, leadership, coaching, and team building become significant new skills required for Business Analysts on Agile development. Leadership and collaboration are key components critical to their success.

Forces:

  • Business Analysts often possess a tremendous amount of system knowledge.
  • Business Analysts are conditioned to believe that they can and should define detailed requirements at the beginning of a project.
  • Assumes that the customer can definitively know, articulate, and functionally define what the system or software should do at the end of the project
  • Assumes that, once documented, the requirements will not change – at least not without potential project delays, budget overruns, or stunted feature sets
  • Assumes that the requirements process is confined to a single product owner who sits apart from the development team envisioning the product
  • Does not acknowledge the inherent uncertainty in software development that Agile methodologies seek to embrace
  • We begin to realize that change really is good, it helps us deliver greater value to our customers and attempting to define everything up front results in constant change management.
  • The very act of creating the requirements will cause them to change.
  • When processes are not static and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability.
  • ultimately the team is on the hook for delivery.

As an agile business analyst, you ought to:

  • Become part of the team involving other members in creating specifications and helping to create a high trust environment.
  • Understand that great teams build great products and those teams should be trusted and empowered to deliver.
  • Collect, distill, refine and manage requirements until they are ready to build.
  • Help create a culture of empowerment and trust, and an environment where individuals are motivated to contribute to the team’s success.
  • Work with the scrum master to maintain the structure and discipline of the team.
  • Be an enabler of the team.
  • Help the team stay focused on the larger business issues.
  • Remove obstacles that impact the team’s ability to deliver, together with the scrum master and product owner.
  • Facilitate communication and understanding and see that as your primary role. Everything is subject to that.
  • Facilitate the conversation between the product owner, executives, the technical team, and the QA team.
  • Ensure that the full scope of requirements has been defined and balanced by an overall technical understanding of the solution.
  • Begin incrementally looking at the depth of the solution when the time is there, usually a couple of sprints ahead.
  • Increase the level of interaction to ensure the team develops specifications that can be built and tested within the overall product constraints.
  • Define specifications breadth first and then depth. It is essential that we understand the breadth of what we want to build early in the project. Dealing with the breadth of the solution helps the team understand scope and cost and will facilitate estimating and release planning. The breadth of a project begins to frame the boundaries of the project and helps to manage the organization’s expectations. Looking at the breadth of the requirements is a much smaller investment of time and resources than dealing with the entire depth. The details are most likely to evolve as we progress through the project so defining them early has less value.
  • Draw out functional requirements from the product owner.
  • Rely much more on people facilitation skills
  • Translate user needs into more technical language for developers.
  • Learn more about how to write their requirements to foster enable feature driven development.
  • Develop a good understanding of software architecture concepts to bridge the gap between the development team and the business and enable the Business Analyst to show how features will be implemented in the resulting system.
  • Understand Agile team dynamics and the organizational and cultural impact of agile transformation.
  • Facilitate collaborative decision-making techniques because agile requirements definition involve a myriad of stakeholders whose interests must be balanced.
  • Specify a more robust solution that meets the evolving needs of the business.
  • Help create a strong sense of confidence that the solution can be delivered to market.
  • Help the team coalesce around the iteration objectives, understanding the requirements at a lower level of detail
  • Bring the team together to deliver an acceptable outcome.
  • Fill the role of a customer proxy puts a significant amount of additional responsibility on the role of the BA.
  • Understand the needs of the customer and translate those needs to the development team.
  • Encourage the product owner to review the evolving system as frequently as possible in order to mitigate the risk of not having a customer on site.
  • Help set the stage for an agile transition.
  • Encourage collaboration between the product owners and the technical teams. This step alone will ensure that requirements are balanced with feasibility. This will go a long way toward managing expectations and helping the product owner understand the cost of the solution they are conceiving.
  • Demonstrate the value of loosely coupled functional specifications.
  • Begin introducing use cases or user stories to the development team to help the team derive value from a clear functionally-driven specification.
  • The system will be easier to develop and easier to test, and traceability will be a non-issue.
  • Test plans can be derived directly from functional organized specifications.
  • Be able to support multiple development teams simultaneously.
  • Represent the product owner at all times.
  • Work closely together with troupe of mercenary analysts when refining and writing user stories.
  • Create and evolve a community of practice and an excellence guide for your profession.

Role description

  • Capturing of detailed requirements from the Business
  • Understanding business processes
  • Translating into functional requirements using Use Cases and User Stories
  • Facilitate workshops
  • Conceptualise UI design
  • Work with the QA's so that requirements are fully testable
  • Find acceptance criteria
  • Gherkin Syntax
  • BDD Processes
  • Represent end users during development
  • Demonstration of software to end users
  • Collating feedback
  • Facilitating UAT with the business
  • Arranging training requirements
  • Ability to work closely together with business and developer
  • Problem solver
  • Pro active, strong drive to deliver
  • Very good communicator
  • Fluent in English

Agile exposure

Agile, Lean, Scrum, Kanban environment

  • Experience working closely with Product Development teams.
  • Extensive knowledge of User Stories and Use Cases
  • A proven track record in gathering multiple requirements
  • Interaction with software developers and testers

Skills

Desirable experience:

Sources

To process

Retrieved from "http://pearllanguage.org/index.php?title=Agile_business_analyst&oldid=339"