Understanding Product Owner Role

Responsibility

Must have a Shared Vision
Developing Winning product

Product Owner controls the development effort in order
to create a product

Other Features

A) Create Product Vision
B) Maintaining the product backlog
C) Release plan
D) Involve Customers, members and stakeholders
E) Manage Budget
F) Manage product start
G) Visit Scrum meetings and Communicate with Development Team
H) Manage Product
As ScrumTeam Member – closely communicate with DM team

A) Be sure that resulting tasks are done
B) Require the estimated Product Backlog from Development Team.

Story Points in estimating work

One of effective way to estimate the work in software development is to use Story points. The story points are based on size and complexity, not duration. They are also become unitless, they not measured by time or another units. One other good quality of story points is that they are additive, unlike time. Also they extremely easy to understand.

User Story Scenarios

Each User Story needs to be testable, need to demonstrate, that requirement has been met. Here is effective formula, which demonstrate, that specific user story has been met:

User Stories

User Stories are an Agile term for what traditionally have been called “software requirements“. They are a brief statements of the intent or need that the system must do for a particular users.

Integration Team in Multi-team Scrum

If one team in Scrum not enough, it’s advisable use Multi Team. But here you get one more problem – how to manage more than one team. And the answer: use the Integration team. With Multi Team your Scrum will look a little bit different.

Multi-team Sprint Planning

All the teams or at least representatives from each team get together
Product Owner gives the vision for the Sprint
Representatives figure out dependencies
Representatives figure out how to minimize cross-team dependencies
Then each team make their usual Sprint Planning meetings

Integration Team’s Daily Scrum

Not the same as a regular team’s Daily Scrum – not “3 Questions”
This meeting kann last less than 15 minutes
Goal: Is the integration on track?
– “Did we have any trouble integrating yesterday?”
– “Are there any likely integration troubles facing us today?”

Multi-team Sprint Review

Goal: Show off the done, working, integrated software and gather feedback

Multi-team Sprint Retrospectives

Representatives from the teams come together
Discuss and identify any cross-team problems
Representatives go into their regular Sprint Retrospectives

Scrum with Multiple Teams

Scrum says a team should be 3 to 9 people. But sometimes you want or need to go faster, so you add more teams. This process calls Multi-team Scrum or Scaled Scrum.

Challenges of Multi-team Scrum

Now you need to coordinate not only a single team anymore
Scrum Master need pay attention to dependencies in the Product Backlog
Manage also dependencies in the Sprint
New responsibility – integrate work from multiple teams

Done on One Team vs. Multiple Teams

In Single Team
– Goal: done, working software.
-If it doesn’t meet the DoD, it’s not done.

In Multiple Teams
– Goal: done, working, integrated software.
– If it doesn’t meet the DoD and if it isn’t integrated, it’s not done.

Multi-team PBI Recommendations

PBIs should done by one team in one Sprint
Manage dependencies between PBIs
Create a new integration team: Job is to make sure everything is integrated
One Product Owner for all the teams
-One product – one Product Owner

How do you make Scrum under Waterfall?

Very often the Scrum under Waterfall exist in organisations. It might not exist formally, but it can be required by contract or by law. The Scrum can be part of the Agile experiment.
The Scrum under Waterfall be because it’s practically for the organisation.

What will be the same/different using Scrum under Waterfall?

Same

Focus on ‘Definition of Done’
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective

Different

Backlog = Project Plan
Less time on Backlog refinement
Less time on Sprint planning
Less negotiation during Sprint

But be aware, during Waterfall delivery:

Waterfall has poor communication / misunderstandings
Lack of transparency
Detachment from reality
Slow feedback / No feedback
Nothing is Done

So you need to do following things:

1: Work in Sprints

The Waterfall can be scheduled for example 12 months. If one Sprint last 30 days, you will have 12 Sprints.

2: Avoid ‘Earned Value’

The task can’t be done for 85.6 or 98%. The task is done or not done!

3: Focus on Done

Create a Definition of Done (DoD), work with DoD

4: Testing, testing, testing

Test throughout Sprints, start to design your tests at the beginning of project. Test until the end

5: Get Frequent Feedback

Gather feedback early. Show the increment before it’s actually due

Waterfall vs. Scrum

What is “Waterfall”?

Waterfall is a plan-driven project management in software development. So normally you work with Gantt charts & Microsoft Project, you have Start & end dates and Project phases. In Waterfall, development phases have force defined order: first you write Requirements, than you Design and Develop your application and at the end coming Testing and Deployment phase.

Waterfall vs. Scrum

Waterfall

Requirements documents
Resistant to change
-Change is a bug
Poor “customer” involvement
Start-to-finish Project Plan
Large team size
Multiple phases
-eventual delivery
Contract driven
-Fixed feature set

Scrum

Just-in-time requirements
Continuos change
-Change is a feature
Permanent “customer” involvement
Plan for the Sprint. Product Backlog
Small teams (3 to 9 people)
Increment every Sprint
Contract is closer to T&E
-Likely not a fixed feature set

Definition of DONE in Software Developent

Let’s imagine, that at the end of every iteration in SCRUM or any other Agile Software Development method, the developer is coming to you and saying: “I’m done with this functionality!” But you of course ask: “What do you mean done? Are you done or done done?”

What do I want to say here: Software developers think that software development begins and ends with them. It’s actually not really false, but…
The software development is much bigger than only writing the code. Code by itself isn’t that useful. When developing team is stating define Definition of Done (DoD), it will be much more than “just coding”.

Example Definition of Done

Development / Coding

Code is written with unit tests
Code has been merged to Main
Code reviewed by someone other than the author

Testing / Deployment

Written QA tests
Tested by QC
Tested by QA
Written UI tests
Accepted by Product Owner
Load tested Deployed to Production

As you can see, the real Done functionality contains much more steps, as just only code. And how to determine this Definition of Done (DoD)?

Defining Definition of Done (DoD)

Get the team together before or just at the project beginning
Start to discus in which phase your functionality can be named as DONE
Try to avoid ambiguity and differences in definition
Write it down!
All team members should follow the DoD

So in next, when developer will come and say:”I’m done!”, all will know exactly what does it mean.

9 main Agile software development Methodologies

Agile Modeling

Set of concepts, principles and techniques (practices) that enables you to quickly and easily perform design and documentation for software development projects. Does not include detailed instructions on designing, contains descriptions of how to build diagrams in UML. The main goal – effective modeling and documentation; but does not include programming and testing, the question does not include project management, deployment and maintenance of the system. However, involves checking the model code.