The Business Analyst Role in
Agile Projects
Dananthi Arnott, Agile Coach and Trainer
LinkedIn
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
Product Owner Role
Iterative and Incremental Development
Refer to Slide note : Agile Project Life Cycle
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.
Iterative and Incremental Development









Refer to Slide Notes:

 


 

 


 



 


 

Success Criteria for Managing the PBL
A well-groomed and managed Product Backlog is a prerequisite for creating a successful product. How?
1.
Stories must be well written :
• How many stories?
• how much detail ?
• when should they be done?
2.
Stories must be prioritized (Business Value, Risk, complexity …)
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:
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.
http://www.executivebrief.com/blogs/software-architecture-agileenvironment-sashimi-approach/
http://msdn.microsoft.com/en-us/architecture/ff476940.aspx
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:
1. Create an Initial Release Plan with the team (why?)
• Initial Estimate in Story Points
• Risks
• Constraints
2. Make sure the stories in the Product Backlog is detailed enough in readiness
for the first two iterations.
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
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.
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
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)
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.
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
What else?
Time
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.
What else?
Time
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
Iteration /Project Retrospective
• 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?
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?
Thank you