0:12
It seems like it makes sense and
it's actually quite common in software development.
The terms estimate, target, and commitment are often thrown around loosely,
and sometimes used interchangeably.
But these terms are actually very different, and it's important, for
the sake of you and your development team, that you differentiate the terms.
Let's go through these terms individually.
An estimate is a guess for the time it will take for your development team to complete a task.
These should be based on some sort of data,
like previous times of similar tasks.
2:18
You guess that it'll take him five hours. Greg has just written tests for
a similar feature and it took him six hours.
He wants to give himself some cushion room, so
he tells you it will take him ten hours.
You think that maybe you could split the difference and write down seven and
a half hours.
2:50
As we've said before, you want to base your time estimates on previous,
similar work.
It's the most accurate way to get estimates,
especially if done by the same person.
Therefore, answer B is correct.
3:04
When estimates are based upon how long a developer wants to complete their task, or
based on how long a manager wants the developer to complete the task,
you risk over or under estimating the time it'll actually take.
Answers A and C are incorrect.
4:34
It is very common that estimates are automatically
converted into commitments and targets.
If you are asked how long it is going to take to make a product and
you estimate seven months then that seven months becomes your commitment.
And the date, seven months down the line becomes your target.
5:08
If I were to ask them for a commitment, in the sense that,
if they are not home at that time, I'm going to triple my baby-sitting fees.
They might say 12:30, to give themselves some buffer time
in case they want to stay longer, or the commute takes longer than expected.
5:24
Ideally you want to discuss estimates with your development team and
come up with some accurate numbers.
You'll also want to talk to your client about target dates.
Then based on these items,
create commitments with your development team and your client.
5:40
You are meeting with your client and development team.
You have already talked to your development team, and
they have determined that, based on their previous work, this project should take
them about eight months to complete with all the features that the client wants.
6:43
The six months that it actually took your team to develop all the features
is not an estimate target or commitment for this scenario.
However, you could use this development time to create estimates for
future projects.
Answer C is also incorrect.
6:59
Your development team and
client negotiated the scope that contained about five months of work.
That would be the commitment.
It was what your team actually committed to developing.
Therefore, answer D is the correct answer.
7:27
Keep these items separate, and make sure that your team and
your client does as well.
It will keep your scope from getting too large,
as well as it will make sure that you can actually meet target dates.
Let's see how those in the industry deal with large projects involving many people.
[MUSIC]
>> One of the techniques that our project managers use to manage multiple projects
is the use of what we call Streams.
So I might create streams of activities or streams of projects where we would assign
a project coordinator or project manager underneath that program manager.
Really understanding what is required within each of
those projects, what the deliverables are.
So that we can roll those up and
understand the interdependencies at a program level.
Typically multiple projects are related to one another.
When they are related to one another, understanding how they
actually are interdependent in terms of predecessors and
successors, in terms of what needs to be done first and what needs to be done next.
So rolling that up into an overall
8:33
schedule helps our project managers better understand how they inter-relate.
As well we might use Work Breakdown Structures to understand all the work
packages that are required that might inter-relate.
[MUSIC]
>> We use a few different mediums to report to our clients, our managers,
our executives, amongst our projects.
Different communication methods including status reports.
Different meeting minutes.
We use actions logs.
We use risk registers as well.
One of the key pieces that we advise our project managers and
product managers is to ensure we also use informal communication.
Making sure that we are not providing any surprises in any of our documentation.
And so sort of having that ad hoc kind of drive by communication,
making sure we're socializing different things, risk perhaps or
issues that may arise to our stakeholders, especially the executive team.
That executive team may or
may not always have the time to actually read some of the documentation, and
read status reports and risk registers and things that have a lot of detail.
So how are you gonna create new communication mediums
to actually tailor to some of those more busy audiences and stakeholders?
So for us we use a no-surprise philosophy, and we ensure that we have some of those
drive-bys socialized different ideas verbally or over the phone.
9:59
In terms of agile practices, and some of the challenges that we face,
you know we're a virtual community across several branches across North America.
And so, one of the challenges that we face is really understanding and
managing virtual teams.
So, how do we collaborate?
How do we do things like scrum meetings when not everybody is physically present?
And so that collaboration, and that unification across
the teams across different locations, is a little bit of a challenge for us.
[MUSIC]
>> Todd Birzer, who's a consultant with Kevolve Product Management,
has a great way of defining this.
He looks a four different areas that product managers are responsible for.
So the four are: market intelligence, product strategy,
product development, and lifecycle management.
So briefly with market intelligence you are researching what's going on in
the market, what's popular, what are the solutions that people are using,
what type of monetization models are being used, what are our customers or
potential customers doing, and what technology is available for
us to use out there that will help solve problems.
With product strategy, we're looking at monetization models and a fit
11:14
between the context of where we're doing development and the technology
capabilities, and then mostly, most importantly is defining a differentiator.
How are we different from other people?
And how do we solve a problem for real people who are out
wandering around in the world who need our help with technology?
And then from there, when we have that nailed down,
we look at starting to road map.
So coming out with a plan of how we're going to build something.
What that should look like.
11:48
Well, there's a classic agency problem,
which means different people are awarded differently.
They're looking for different things out of a product, and
in software development, it's incredibly resource-intensive,
and it doesn't always quickly as these groups would like.
[MUSIC]
That's incredibly difficult.
It's a lot of time spent talking to people, finding out what their needs are,
finding out what their perspective is and finding out common ground.
So it can be reasonably straightforward with a new venture, where
people, a lot of the ideas are fresh and there is a lot of a shared experience.
But typically the different groups have very different goals and
different personalities in working styles and
they require different environments and context to do their work.
So they may use different language.
So technical people will use technical jargon and
so that can be off putting or misunderstood by other groups.
So there's often a lot of what on the surface feels like conflict. So
a lot of the work that I do is I try to find common ground.
So on some projects I interview people and I do affinity maps.
I'll take out different colored markers and get out the thesaurus and
I'll look at nouns and verbs and adjectives and highlight them and
then say okay you're actually saying the same thing.
And finding that common ground, that commonality.
The other thing that's important there is when there's a focus and
a differentiator, and reminding people why we're in business.
What's the problem that we're solving for a particular particular user.
If we can bring that 40,000 foot view into our conversations to help set the context,
that really helps keep people focused.
>> In the next module, Bradley is going to teach you how to create accurate estimates
and how you can use these estimates to organize tasks for a project release.