A Business Analyst and a Project Manager Walk into an ... · A Business Analyst and a Project...

A Business Analyst and a Project Manager Walk into an Agile Bar…

Jennifer Battan, CBAP®, CSM, CSPOPaul Crosby, PMP

What can I get you?

AnAgile Project,

or anAgile Product?

Establish the Working Agreement

• In the beginning of the project, during or before sprint 0, a working agreement needs to established. The working agreement details how you as a team will operate.

• Effective working agreements are made by the team, not dictated top down.

Defining Done

• Another early task for the team is to create their Definition of Done. This is what the team agrees will enhance the quality of the work, but not the work itself. Usually a “checklist” of tasks that must be completed before a PBI is considered “potentially shippable.”

• DoD goes hand in hand with working agreements, to some extent.

There are no BAs or PMs in Agile.

Tell me your troubles.

As a PM, I am used to receiving a project with a defined delivery date and a set budget. I can pull together a team and deliver per the request.

Why a Story Map?

• Puts your vision into a realistic, tactical approach.

• Shows what the goals are and when they will be achieved• Defined by the Product

Owner• Usually “quarterly”• SIGNIFICANT

Story Map Types/VisualizationsTraditional Story Map A Functional Decomposition

Story Map Steps

1. OPTIONAL: Identify the Personas that will gain value from the product. Who will benefit, when will that benefit be realized.

2. Major goals, objectives, themes or capabilities are sequenced as to when they need to be realized or available.

3. Goals or themes are broken up into steps, activities, or functions that provide value.

4. Functions or steps are broken into features and become right-sized stories or PBIs.


Story Splitting. I write stories that seem “right sized” and one day the stories are too small and the developers bundle them up into one thing, and the next time they say they are too big and I have to break things apart. I don’t know if I’ll ever make them happy!

Early Tech Estimates

• Practitioners talk about PBIs being estimable at any time, yet the Sprint Planning event is the only time most of us talk about estimates.

• Work with the team early to identify a method for early estimates, even without a story fully defined. This will ensure that stories that are deemed Sprint ready are also right sized.


As a BA, I’m used to having a lot of time to really work with the business to understand their requirements and the product they want built.

Is your backlog an iceberg? It should be.

Via Mountain Goat Software

What is Urgent is seldom Important

• When work is selected at each iteration without a goal or guiding principle, priority may be based on short sighted decisions

• It’s a TRAP!• The temptation is to prioritize based on the

crisis du jour: production issues, sales requests, whomever is complaining ‘loudest.’

• It’s not strategic


As a PM, when things “go wrong” on a project, I usually have a lot of lead time. I can manage risk. I can see dates slipping and I can make corrections.

If only we had a tool for that…Enjoyable

Usable

Reliable

Functional


As a BA, I sort of “start” the project. Without requirements, developers don’t have anything to build. Are they going to be twiddling their thumbs waiting for user stories?

The “DAPPER” Backlog

• Detailed – detailed sufficiently for development to begin

• Adjusted – changed or modified to meet a customer’s current needs

• Prioritized – ranked in order of importance

• Proved – has demonstrated a valid customer need through evidence or discussion

• Estimated – approximate or roughly calculated effort

• Related – connections or relationships to other user stories is confirmed

Types of Items in the Backlog

Theme– large focus areas. These could span an organization, multiple products or serve as an organizational tool for the product.

Epic- A large body of work that will be broken down into smaller tasks or stories. Sometimes an epic is just a really big story that hasn’t been refined yet.

User Story- now sometimes called a "PBI" or Product Backlog Item. Stories are short requirements written from the perspective of an end user.

Tech or Task- cards that are technical "to do" items but do not add functionality to the potentially shippable product.

Spike – cards that indicate research needs to happen before another story can be started

Other Item Types: other items the team could choose to use. For example: Bugs – testing defects, Improvement –items from a retrospective or that remove an impediment, or Tickets – operational activities or support.

Spike Definition

Spike a short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story.

Sometimes the outcome of a spike is to do another spike!

Spikes

• A card or task focused on research or gathering information used when a user story can’t be estimated or developed because there is a significant lack of information missing

• A spike doesn’t deliver a product to the customer

• Can happen with overly large and complex stories

Spikes

• These cards take away time from the sprint

• Spikes can be used to create prototypes to develop knowledge needed for solution design

• A spike is taking time to make a story estimable

• Spike cards are estimated to ensure they will fit into a sprint


We don’t have a “real” Product Owner. We have a governance team that makes decisions, but they don’t do all of the other stuff to support development.

Scrum Roles

Scrum Team – group of individuals usually between 6– 8 people with various skill sets

Scrum Master - dedicating to facilitating the team to maintain velocity and consistent performance by removing roadblocks, establishing team environments, addressing team dynamics, and preventing the team from having outside interruptions

Product Owner – empowered to make decisions on the product solution

Developer – designer and creator of the solution

Tester – not typically used, dedicate resource for ensuring compliance and meeting quality standards

Hundreds of Way to Report Status

• Daily standup is one type of communication of status in a scrum team

• Mid-sprint and completed sprint status reports are typically used to communicate status outside of the team

• Know your audience and how they want to get status before sending it off

• Some PMOs require weekly status reports

What to Report

ü Roadblocks

ü Risks

ü Accomplishments

ü Lessons Learned

ü Process Improvement Changes

ü Planned versus expected versus actual

ü Indication of which sprint you are working on and how many sprints are planned

ü Coming up next – what to expect

Sprint Burndown

Day 0 Day 5 Day 10 Day 15

Planned Points 20 13 6 0

Actual Points 20 9

20

13

6

0

20

9

0

5

10

15

20

25

STO

RY

PO

INT

S R

EM

AIN

ING

DAYS

Compares the planned versus actual story points that are REMAINING

The difference between actual and planned is a gap

Are we behind?

Sprint Burnup

Day 0 Day 5 Day 10 Day 15

Planned Points 0 5 10 20

Actual Points 0 9

0

5

10

20

0

9

0

5

10

15

20

25

STO

RY

PO

INT

S R

EM

AIN

ING

DAYS

Compares the planned versus actual story points that are COMPLETED

The difference between actual and planned is a gap

Are we behind?


The lead developer on the team is the system expert. She gets pulled in to every production issue. We can’t just “not do” production support.

Tuckman Team Building

FormingStorming

NormingPerforming

Adjourning

Resource Problems

• Team Member has left the building

• There’s a production problem

• Lack of Team Member experience


I’m being asked to write mini-functional specification documents for every feature. If I don’t identify the table where data needs to saved, the team won’t point the story.

Remember the Working Agreement?

• In the beginning of the project during or before sprint 0 planning, a working agreement was established. The working agreement details how you as a team will operate.

• Due to the theory of progressive elaboration, the more you know and work with something the more you understand it and thus changes to the working agreement become needed.

• Retrospectives can drive changes to the working agreement as you learn to work together as a team more effectively.

User Story Problems

Team doesn’t understand the user story

There’s a technical roadblock during development

Team discovers a new user story is needed

Set WIP

• For each stage in your Kanban board you will need to establish a limit or maximum amount of work that can be placed in that workflow stage

• Effort is determined by the estimate you give to each card

Well That Wasn’t Supposed to Happen

Your supplier for the ice cream machine isn’t agile

Your organization hired a company to perform training, but they aren’t agile either

You need to integrate with the database team, but they don’t see you as a priority

You’re getting code from a team that is strictly waterfall and wants a specific design established prior to starting their development for you. Your team hasn’t got to that part of the design yet.

Retrospective ValueFa

ilure!

Status

QuoNo learning from

failure so it keeps

happening

Lost Team

Productivity

Increased Team

ProductivityLearning from

failure to eliminate

avoid failuresRetro

spec

tive

Happe

ns

Time

Retrospective Value

Consistent Retrospectives Start

Status

Quo

Lost Team

Productivity

Time

Team keeps growing and learning!

Yes there are failures, but correcting those failures quickly keeps

the team moving upwards to greater productivity!

Increased

Team

Productivity

Continuous Improvement

Agile and Scrum builds continuous improvement into the

retrospective

Holding retrospectives are important to helping make the

team more effective and efficient in future sprints

Experiential Learning Model

What is PDCA?

Continuous Improvements Principles

• The biggest improvements are the small ones that are easy to implement

• Every team member has good improvement ideas

• Every team member assists in creating improvement changes

• Reflect back in order to learn

• Continuously improve after each and every sprint• Prioritize and pick the top 3 – 5 improvement ideas by the

team• Generating process improvement ideas and not doing

anything to implement them deflates the team

A Business Analyst and a Project Manager Walk into an ... · A Business Analyst and a Project...

Documents

Transcript of A Business Analyst and a Project Manager Walk into an ... · A Business Analyst and a Project...