As a Project Manager, my tasks include the traditional:

Project Financials & Financial/Portfolio Reporting

Status Reporting
Project Governance
Identification of missing roles/resources and resolution/escalation of same
Business stakeholder communication
Issue/Risk communication/resolution/escalation removing blockers
Project Planning
Change Management

As a Scrum Master (SM), Im also responsible for:

Ensuring the team adheres to its processes (and all that entails in terms of
artifacts and meetings)
Resolution/escalation of inadequate or ill-defined user stories ensuring
Product Owner accountability
Removing barriers and shielding the team from external interference
Conventional wisdom suggests that the Project Manager and Scrum Master roles are
in conflict, owing to the PM role being one of command and control and the SM
persona being very much that of a servant leader. I have always seen myself as
that servant leader since, not being a technical expert or a SME, my job is to keep
the project on track and remove blockers to progress.

I am currently combined PM/SM on three projects and purely PM on a fourth, with

my role on that fourth project being to manage tasks and obstacles that fall outside
of the sprint (e.g. data acquisition from source/transactional systems), and I do not
feel it is a diminished role; having a Scrum Master take on daily project activities
frees me up for other projects and to take on more. That said, the combined PM/SM
role is often attractive to managers and clients because it obviates the need to hire
a separate Scrum Master.

One area that frequently struggles with the transition to Agile is that of
project financials. Funding for an Agile project would be in iterative chunks,
feeding directly into value of throughput for the Business by the delivery
team. I have heard this referred to as a factory model, suggesting an
assembly line approach to development this isnt wholly inappropriate
given that so much of Lean and Agile grew out of manufacturing. Budgets for
projects are arrived at with an estimation approach that is still rooted in the
world of waterfall-run projects (I have had interesting conversations with
personnel in Finance when providing administrative details such as what is
the In Service date for an Agile project). However, one of my projects that
is run Agile is currently in the fifth phase of development this suggests that
delivery of previous requirements has bred trust between the product owner
and project team to the extent that they have renewed our funding based on
the product owners confidence that we will meet his changing requirements
and provide what he needs to stay competitive and efficient. Its not a blank
cheque, but it comes close to a factory model.

In line with the challenge just mentioned, Product Owners are constantly
desirous of knowing how much scope may be accomplished given what is left
in the project budget. I actually find that I have a better grasp on the realities
of what we can and cannot deliver within budget using an incremental
delivery approach. In my PM/SM hybrid persona, I use Release Planning as
well as team velocity and burn rate to provide the product owner with such
an estimate. My caveat to the product owner is always that release planning
activities take the core team away from delivering user stories, so that is a
trade-off that the Business needs to make. This usually discourages the
product owner from constant demands along these lines!

Velocity
How to Calculate and Use Velocity to Help Your Team and Your
Projects

What is velocity?
The truth is: Velocity is velocity. And velocity is measured . . . as velocity is.

How do you measure your velocity while driving? (Imagine the speedometer is broken.) You've
been driving for the last two hours, you've gone 160 kilometers, so you know your average
velocity is 80 km per hour.

If your final destiny is about 200 km away from your starting point:

You know you will likely get there in 30 minutes, or

If you stop now you have already gone 160 km, or

If you need to stop and fuel up in 15 minutes, you can say you've done 180 km.

The same goes for projects: Team velocity is the rate at which a team delivers stories from the
product backlog. If you know your velocity, you'll have an idea about:

How much value you've delivered until now (in story points and done user stories), and

When you'll be able to deliver all user stories in the product backlog, and
 How many story points will you be able to deliver by a certain date.

How do we calculate velocity?

Simple! We do some basic math.

Scenario: Our team delivers 3 user stories. The sum of the story points equals 20. Our velocity
is then 20.

If, in the next iteration, our team delivers 30 story points, then our average velocity is 25, or (20
SP + 30 SP) divided by 2 iterations = 25 SP.

Figure 1: Awesome handmade velocity chart

Velocity is the number of story points completed by a team in an iteration.

Why do we need it?

We need velocity to:

Predict how much scope can be delivered by a specific date

Predict a date for a fixed amount of scope to be delivered

 Understand our limits while defining the amount of scope we will commit for a sprint

What influences velocity?

As in a car trip, there are factors that may influence our velocity:

Roadblocks -- aka impediments

Fuel -- motivation, what drives us

Driver experience -- knowledge/expertise/competence developer

Car conditions -- dev environment

Visibility -- project transparency

Directions -- project objectives

Traffic/driving rules -- processes

Destination -- product

So think: If all those things are in bad shape, or without proper definition, then your velocity
decreases. The same applies to projects.

Can I count in an incomplete user story?

No, you shouldn't. Incomplete is undone. Velocity is about finished, delivered user stories. Here
are some reasons why you shouldn't count incomplete user stories:

We can't really figure out how much is ready and how much is not; it will be a wild guess.

We may be led by a false sense of accuracy, due to the use of fractional numbers.

Incomplete means the user story still has no value for the customer.

So what should I do with those user stories?

Break the user stories into smaller ones. That way it will be easier for you to add them to a
sprint and manage to deliver them.
Teams and their velocity
Should bugs and maintenance be considered in velocity estimation?

Yes, if you estimate their size in story points. It's work delivered, right? Although with no direct
value to the customer, this work is indirectly associated with value delivered. The proper way to
handle this is: Don't create bugs(!). Use zero-bugs & prio1-fix-bugs policies. Whenever a bug
pops up, finish it off!

Should I compare the velocity of different teams?

No.

Why not? Well, because we work with story points. Therefore we work with relative estimation;
we compare user stories with each other, having as our basis a reference user story that the
team picked up. The story points of that reference user story could be anything. A team could
say that the reference user story is equal to 400 SP or equal to 2 SP. It actually doesn't matter,
because we work with relative estimates.

The goal is not the number itself -- the goal is to use this user story as a reference so we can
estimate other user stories by comparison.

So, how would we compare velocity in this case?

Team A is delivering 800 SP and Team B is delivering 30 SP. Does this mean A is better than B?

I don't know! And I don't care. Each team is comparable only to itself. Velocity is not used as a
measure as if we were racing against each other. Velocity is used to help us improve our own
timing -- to help us get better and better and speed up, compared only to ourselves.

What about teams working with the same product backlog?

This is a different case. It is nonsense to have teams using different units of comparison for the
user stories in the same product backlog. We use story points to predict how much scope we'll
be able to deliver by a certain date, or to predict when we may be able to deliver the scope. So
if we have more than one team working on a backlog item and they use different sizes for the
user story, we won't be able to make this prediction.

In this case, teams must get together and define a reference user story. Afterward they should
decide on the size of that user story in story points. Then, in every refinement, the teams (or
their representatives) will estimate, using the same user story and the same size for
comparison.

Then, in this case, can I compare teams?

Nope. Why would you? Maybe some are delivering fewer story points because those user
stories were not well estimated compared to others. Or maybe that team is helping other teams
or paying more attention to testing, refactoring, coding standards. . . . We don't know, do we?
You should compare a team with itself, and dig out why the team is slowing down (if it is).
Probably you'll see there are several impediments you need to take care of.
Each car has its own characteristics. We need to get the best from each, knowing that if we
push too hard, we will probably break the engine.

Help teams excel, don't punish them.

Humans are humans, and we are (gladly) different from each other. You'll always have teams
performing differently from each other -- and that's not necessarily bad. We just need to find out
each team's own sustainable pace and keep them moving, driving our company further.