1. The Business Analyst Role in Agile Projects
Dananthi Arnott, Agile Coach and Trainer
LinkedIn

2. What are your choices?
Path One : Transition to a “Product Owner” role and help drive the project and manage the Product Backlog
Path Two: Assist the Product Owner as the “Technical Product Owner” – Write User Stories (Requirements) and Acceptance Criteria; Manage the Product Backlog; provide feedback; respond to change; collaborate with team; manage Stakeholder expectations
At a high-level, the Product Owner:
Defines the project vision and goals
Specifies WHAT the project should deliver
Prioritizes functionality for delivery, and
Accepts or rejects delivered project work
Analyze Risk
Make decisions related to scope, schedule
Control change: Based on what is being delivered and any other environment factors, adds or changes scope and the direction, leading the team, and focusing on delivering business value

3. Product Owner Role Iterative and Incremental Development
Project time line
What is the Agile Project life cycle?
When an Agile project starts, the core team (Product Owner, Implementers and the ScrumMaster) and Stakeholders, come together at a project kick-off meeting called the Iteration zero meeting to understand the project scope and project timelines. The Product Owner communicates the project scope, which is a prioritized list of work items, also known as the Product Backlog.
During the Iteration zero meeting, the team members discuss the project details and provide a high level estimate of the work items on the Product Backlog. The idea is to be able to size the Product Backlog using relative estimates, i.e. Story Points. The Product Owner uses this information and feedback from the team to further refine the Product Backlog and create a Baseline Release Plan, in readiness for iterative and incremental development of the product.
The Agile project life cycle is composed of multiple iterations with a fixed duration of not more than 4 weeks in length. At the end of each Iteration the team delivers an increment of software i.e. "potentially shippable product", that is completed as per the agreed upon Definition of Done.
At the beginning of the Iteration the team gets together to decide how much work they should commit to the Iteration. This is called the Iteration Planning meeting. In the Iteration Planning meeting the team selects the highest priority items from the Product Backlog, breaks it down into a more granular level and estimates the effort needed to complete these tasks. The task estimates are provided in Ideal hours. The goal of the Iteration Planning meeting is for the team to commit to a reasonable amount of work for the Iteration, i.e. Iteration Backlog, and make decisions on how to implement the work that is committed to the Iteration.
During the Iteration the team gets together daily, in a daily stand-up meeting, to address challenges and obstacles, share progress, to inspect and adapt, in order to meet the team commitment.
At the end of the Iteration, the team reviews and demonstrates the work that was completed in the Iteration. A Retrospective is conducted for continuous improvement.
This iterative development cycle repeats itself until the work items in the Product Backlog is completed, the budget is depleted or the project deadline is met. The objective is to ensure that the highest priority items with the greatest business value is completed and delivered when the project ends.
During the course of the Project, the Product Owner progressively refines and grooms the Product Backlog, writing user stories and acceptance criteria for the next highest priority items, in readiness for successive Iteration Planning meetings. The Product Owner updates the baseline release plan as new information surface, communicates the changes and manages Stakeholder expectations. The team assists the Product Owner in breaking down epics, detailing and sizing new stories, as needed. The team in collaboration with the Product Owner may schedule a special iteration for stabilizing the product.
Product Requirements are managed using Epics, Themes, User Stories, Spikes, Bugs, Escalation Issues and other work items, which are included in the Product Backlog.
The agile framework provides the team with four events to ensure the team is making progress towards meeting its goals and minimizing deviations and undesirable variances by inspection and adaptation. These are: Iteration Planning Meeting; Daily Stand-Up; Iteration Review/Demo and Iteration Retrospective. At the end of the project the team holds a Project Retrospective.
It also provides a Program management framework and is called a Scrum of Scrums. This frame work provides a structure for multiple teams to collaborate and work together to deliver products incrementally and iteratively, to meet a common release schedule.
Refer to Slide note : Agile Project Life Cycle

4. Note on how to create the Initial Release Plan and/or Create the Project Charter: Establish the high level scope and schedule for the project to obtain project funding and for managing stakeholder expectations. Who takes part in this? May be a subset of the team or perhaps you can get this information from your stakeholders as well. Don’t forget to capture constraints, assumptions and risks.
The initial release plan is at a high level, rough and only detailed enough to get the project started. It will evolve as more information is known about the product, development environment and the team velocity.
The goal is to establish an overall release schedule that presents the timeline in Iterations and defines the preliminary scope that will be delivered at the end of each Iteration.
Release planning can be driven by either the project scope or the project schedule.
If scope drives the project, the goal of the Initial Release Plan is to define a preliminary schedule of work items planned for each Iteration and provide an estimate of the number of Iterations required to deliver the project scope. This is based on the team velocity.
If schedule drives the project, the goal of the Initial Release Plan is to define the scope that can be delivered at the end of each Iteration, based on the team velocity. This provides an estimate of the number of features that can be delivered for the Project.
Suppose it does not go as planned, and you have to stop the project due to any one of these reasons:
Budget has been depleted or
All features in the PBL is ready to be deployed (scope is met) or
Run out of time…scheduled date for delivery has approached.
Your Key to success: Highest priority items in the PBL has been worked on and is ready for delivery.

5. Backlog    Iterative and Incremental Development Project time line
Incrementally and iteratively transform the requirements in the PBL into potentially shippable product increments.
Only demonstrate the work that meets the Definition of Done. Any stories that do not get delivered at the end of the iteration must be re-prioritized in the PBL in readiness for the next planning meeting
Internal defects/change requests, must be triaged and added to the PBL, if story cannot be closed and is not complete, i.e. does not meet the acceptance criteria or the Definition of Done, the work left must be documented and the Story needs to be re-prioritized in the PBL.
It is the responsibility of the Product Owner to continuously evaluate what is in the Product Backlog in preparation for the next Iteration Planning meeting.
Refer to Slide Notes:

6. Success Criteria for Managing the PBL
Backlog
A well-groomed and managed Product Backlog is a prerequisite for creating a successful product. How?
Stories must be well written :
How many stories?
how much detail ?
when should they be done?
Stories must be prioritized (Business Value, Risk, complexity …)
Manage requirements (scope) for the Project and Prioritize the list of work, in readiness for each iteration.
What are User Stories -
1- Stories must be well written (follow the 3 C’s – written on a 4X6 Index Card, open to Conversation and must have Acceptance Criteria). Follow the “INVEST model” when writing the stories and the Product Backlog must have “DEEP” qualities.
2- Stories must have Acceptance criteria {not the same as the Definition of Done}
3- Product Backlog must be prioritized (consider, Business Value, Risk, Complexity, Dependencies etc.)
The goal is to deliver value to the customer, as soon as possible, without compromising on quality.
The INVEST model is used to decompose items in the Product Backlog in readiness for the Iteration Planning meeting, so they are Independent, Negotiable, Valuable, Estimable, Small and Testable.
This is sometimes referred to as having DEEP qualities, meaning: Detailed, Estimated, Emergent and Prioritized.
INVEST -
DEEP -
Another aspect to remember, when writing stories:
Cone of uncertainty -
Law of Diminishing returns -
Key Responsibility: define requirements in smaller increments, prioritize and work more collaboratively with the team to build product iteratively and incrementally
Refer to Slide Notes:

7. FAQ: How do you address the architecture decisions that you need to make at the beginning of a project?
The teams incorporate software architecture in to the agile framework, delivering iteratively and incrementally. It is especially critical to make sure these iterations have definite goals and some of these tasks are time boxed. One common approach is called Sashimi.
Couple of great articles providing in depth discussion on the topic.

8. Project Kickoff Meeting [= Sprint 0 = Iteration 0]
Inputs: Project Charter; Historical Data; Background Information; High level Scope (requirements) should be prioritized in relation to Business value ; Time Lines …
During Iteration zero, the highest priority requirements are further refined and detailed. This is done in collaboration with the team.
The meeting takes place before any development begins and should be time boxed. (recommendation: 1 week)
Output:
Create an Initial Release Plan with the team (why?)
Initial Estimate in Story Points
Risks
Constraints
Make sure the stories in the Product Backlog is detailed enough in readiness for the first two iterations.

9. More on the … Project Kickoff Meeting [= Sprint 0 = Iteration 0]
Activities during this Iteration:
Introduction of the team (core and external team members)
review the Project Charter (Project Risks, Constraints and Assumptions)
Share relevant background information and/or historical documentation
Discuss the initial Release Plan (Road Map; Vision …)
Discuss functional and non-functional requirements
Discuss supported platforms, installations, architecture, security, build frequency and product shipment format
Setup necessary project infrastructure (Team) and include tasks to the PBL if needed
Discuss Beta Releases and the scheduling of Landmark Demos (for major milestones)
Review applicable procedures, discuss testing requirements and escalation process

10. More on the Project Kickoff Meeting (Contd.)
Activities during this Iteration (contd.):
Review the team Definition of Done and agree on the Project Definition of Done. LinkHowTo
Decide the Iteration Length and start dates, venue and times for Daily Stand-Up, Planning meeting, Demo/Review, Retrospective etc.
Evaluate the skill set of the cross functional team members and training requirements
Review lessons learned and/or improvement action items from previous Project Retrospectives
==============
Populate and refine the product backlog with enough stories for the first two Iterations of the project… more detail (why?)
Provide relative estimates for stories in the PBL in Story Points (How? and why?) LinktoStoryPointEstimation
QUALITY – Provide answers to the team on learning WHY? and WHAT? Put it into context.

11. What happens during the Iteration and how do you prepare for the meeting?
Input:
Prioritized Product Backlog
Stories written with just enough detail (follow the 3 Cs. Card/Collaboration/Confirmation)
Make sure you have acceptance criteria defined for each story

12. Are you ready for Iteration Planning?
Input:
Prioritized Product Backlog
Stories written with just enough detail (follow the 3 Cs. -Card/Collaboration/Confirmation)
QUALITY - Make sure you have acceptance criteria defined for each story (Provide context for the story scenario)
At the Iteration Planning meeting:
Explain the highest priority stories to the team at the Planning meeting
Get estimates at the Planning meeting in Ideal hours
If the stories are too big, break them down in to smaller stories or tasks
Review Acceptance Criteria
Review the Definition of Done for the Iteration
As a team, decide on an Iteration Goal that describes the Product increment that will be delivered in the Iteration
Risk discussion (Schedule, meeting the Iteration Goal, team capacity)
Output: a committed list of work items for the Iteration (Iteration Backlog)

13. Iteration Demo/Review
During Iterations
QUALITY – “Power of 3” – Include all team members (Product Owner, QA, Developer) in discussions and meeting decisions
Ensure the team is meeting the Definition of Done for completed stories and tasks
Iteration Demo/Review
Review what was accomplished and what was not completed
Accept or Reject work; provide feedback
Get feedback from Stakeholders:
How useful is the product?
Does it serve the intended purpose?
QUALITY – Provide honest and timely feedback on completed stories. Include key Stakeholders to the Demo/Review
Landmark Demo: Can be used for reviewing related functionality with project sponsors and stakeholders. This is a special demo that is open to a larger audience. Similar to a milestone review, in this case you are demonstrating potentially shippable software or a beta release.

14. Managing and controlling new Information and changes to the Product Backlog
Estimate new work items in Story Points
Reprioritize Product Backlog
Revise Scope/Schedule
Update the Release Plan
Communicate the changes to all stakeholders
Key: maximize business value and customer satisfaction; minimize risk

15. What else? Continuous Release Planning Quality Risk Project time line
Cost
Scope
Quality
Risk
What else?
Project time line
Continuous Release Planning
Some factors that can have an impact on the Baseline Release Plan are:
New and emergent technology
Architecture Design
Domain Knowledge
System design
New information based on spikes related to research, proof of concepts
Team changes
Team expertise
Training
If these factors cause the Release Plan to be revised, the impacts must be communicated.

16. What else? Continuous Release Planning Quality Risk Project time line
Cost
Scope
Quality
Risk
What else?
Project time line
Continuous Release Planning
Continuous release planning is important (why?) :
Review Release Plan; Inspect and Adapt
Address Quality Issues
Risk impact analysis and risk mitigation
Manage Stakeholder expectations
Manage and control project scope
Manage the project schedule

17. Iteration /Project Retrospective
FEEDBACK
TRUST
Participate in the Iteration and Project Retrospectives
Provide honest feedback
Be open to receiving feedback from the team and encourage them to provide you the feedback
QUALITY – Identify process and product quality issues. What works? What can we improve?
RESPECT
COURAGE
Communication

18. Related Topics
Release Planning on agile projects (Story Point estimations, Epics, Themes, User Stories, Prioritization based on Business Value, ROI, Risk, Dependencies etc. Creating a Release Burndown Chart)
How do you write good stories for agile projects? (Understand Use cases, write business scenarios, write Acceptance Criteria. What does just-in-time mean? Breaking down user stories. How do you apply lean software engineering principles? INVEST model – DEEP?)
How is Quality Assurance done on Agile Projects? What is the Definition of Done and how important is it? How do you stabilize the system being built when you are incrementally creating potentially shippable products? Explore the concept of a Special Iteration?
How do you apply the agile framework to a maintenance project? Explore Kanban?
What is an Ideal hour? What are Iteration Burn down charts?
What is Team Velocity?
Are there metrics on agile project? Can you measure team productivity? Can you compare teams? How do metrics affect team performance?

19. Thank you