Software industry is going crazy on agile methods. It is rapidly becoming the choice for software development where requirements are unpredictable or is expected to change over time. This course will help you gain knowledge on what is agile? Why agile is better suited for these situations? We will also cover some of the most common agile frameworks like scrum and XP in depth. Prerequisite: You need basic knowledge of software development process and software development methodologies. After completing this course, you will be able to : 1) Demonstrate the ability to participate effectively in agile practices/process for software development. 2) Explain the purpose behind common agile practices. 3) Ability to apply agile principles and values to a given situation. 4) Ability to identify and address most common problems encountered in adopting Agile methods. Project: You will also be given opportunity to apply what you learn in this course. You will be given fictional case studies, where after studying the case study, you will have to exercise some of the practices, techniques, etc that team members of an agile team members are expected to know.
Estimation Styles and Process
Loading...
Из курса от партнера University of Minnesota
Agile Software Development
105 оценки
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Из урока
Requirements and Planning
In this module we will learn about user stories and agile estimation and planning techniques.
Познакомьтесь с преподавателями
Praveen MittalAdjunct Professor
College of Science and Engineering
In this lesson, we're going to learn about
the estimation process and different estimation styles
that teams use to estimate stories.
So, in terms of estimation process
the main idea is that we want to involve the whole development team
into the estimation so that they own
the estimates and everybody get an idea of what we are about to build.
Now, the question is how long does it take?
Well, it very much depends on the style of the method or style you use.
What kind of method you use?
How many stories are you estimating?
What kind of understanding do developers have about the stories?
What kind of knowledge they have about the technology that they're going to use?
How expert they are?
And then again also it depends on a number of team members.
The more team members sometimes are going to take longer because to build the consensus.
So, definitely how long does it take?
It depends on so many factors that usually cannot give any ballpark figure.
In terms of estimation style,
there are three styles and probably
there are more but we're going to talk about these three.
The first one is a very simple model where it's a free form,
basically if you have a product backlog then you just go first item and then you say,
"Okay, how long does it take?"
Somebody will say, "Well,
it's going to take five ideal days."
"Okay, everybody looks good, everybody feels good.
Yes, okay, I want to look five."
Another item, how long it's going to take?
Somebody says, "Yes, eight."
And then somebody says, "No, I think I don't understand."
And then you go back and forth a little bit of discussion.
But then you come to a consensus of how long the story is going to take.
The second and the third approach is the planning poker and card sorting.
Let's dig deeper into these two styles.
So, in planning poker the process is that, everybody gets together.
Everybody has these estimation cards showing here,
but it doesn't have to be that.
Whatever estimation scale the team uses everybody gets
cards that has the estimation each of those buckets.
Then you basically take a story and then
the product will explain what the story is about,
individuals, the team members can ask questions and if
they don't understand the story they can ask a clarifying question.
Once they have it,
once everybody has understood the story then everybody is going to think about it,
estimate the story, and put one of the card down.
And at the same time everybody is going to open the card and then we will say,
okay, if there is a consensus,
if everybody says let's say three then we're down.
And if everybody says three,
one person says two you can have
quick conversation but we'll just put it in the three and then move on.
But if there is a situation where one of the person has says,
"Well, is going to take one day."
And another person said,
"Has the card of five."
In that case we're going to have conversation between the five,
the person who gave estimate of five,
and the person who gave the estimate of one.
They're going to discuss and hopefully that will
clarify the misunderstanding that one of them had.
Or maybe it will create a better understanding of the story.
But then you go back to the step three and once you
understand the story everybody again then think about,
based on the discussion, that these two people have they based on
that and based on additional information they estimate and then put one card down.
Again, everybody opens the card and then we again see if there is a consensus.
Maybe this time everybody said three, if yes,
then we move on to the next story else we'll do another round.
And you know after one or two rounds you do
come up with at least some estimate and then move on.
So as you can see this is a pretty rigorous process of estimation.
It is very time consuming and but then it can help you uncover misunderstanding.
Because it's not always
if you do a simple math there then the expert person knows you are eight.
And everybody, the junior developer will not even say, "Yes, probably eight."
That's only if her thinks or if he or she thinks eight is probably that.
But here everybody has to think about a story and put the card down.
And if the estimate is incorrect they have to explain what it is.
So, it forces them to be engaged and uncover misunderstanding.
And also brings this collective ownership because everybody is engaged,
and everybody is talking about those stories.
So, it's really good for backlog grooming.
But if you have to do hundreds and hundreds of stories
then this matter could be very time consuming.
Let's talk about another approach card
sorting and there are probably different names about this approach.
So, this approach what you do is let's say you have lots of stories to estimate.
So you pick from this bunch of stories that you want to estimate.
You pick the smallest story and you pick the largest story
just to get a feel for it and you dig these two stories.
And on a big board you put the smallest story on
the left side and you put the largest story on the right.
And then you just let
all the developers come next to the table and just say, "Pick few stories,
go on to the board and put your stories between these two stories,
the smallest and the largest."
And so silently everybody will start placing stories between these two cards.
There are a couple hint or rules.
If you don't understand the story because
there is no discussion happening it's silently, right?
Nobody talks to anyone,
nobody can talk to anyone.
It's just that you pick few stories and you put it.
So if you cleared a separate column
for keeping the story that you have question about or you don't know,
and you can't estimate or you can't even put relatively, so you put separate column.
And then if you see a story,
another story which is on the board,
which is similar size you put it under it.
So you stack the stories which are of similar size.
And let's say you were about to put a story,
so another story that was put by another developer and you
disagree with it so you silently dig that story
and put it at the right place but you don't discuss it.
Everything that is happening so far is silently and then that person can again move it.
But hopefully and if too many back and forth you can put it in the question mark bucket.
But silently everybody put all these stories on
the board and then you discuss the changes.
So, the stories which were on the question board you discuss those and you put
them on the board and then you look at the whole board
all the stories on the board another look.
Everybody looks at the story and if they see anything that doesn't look good they
might move it or if there is a disagreement
then they can discuss and they can move stories if needed.
But then once that is done you create buckets.
So as I said put all the similar stories together and stack them.
So after a while once you put all these stories you create these fuzzy lines and just,
"Okay, these stories all look similar size.
These stories all look similar size."
And then you assign the size to each of the buckets.
Now, if the team already has the estimation scale,
they already were using 1, 2, 4,
8 for rest of their work they don't need to start with no buckets.
They can start with all those buckets pre-define and
then you can still do silently just put in one of those buckets one through four, eight.
So, if you already have a size just you can use the scale from the very beginning.
Now, this kind of sorting is really like I said will be very very
useful if you're estimating large number of stories.
So, here we go we talked about the simple estimation style.
We talked about planning poker and cards sorting.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
