Preface :
It’s time to go to work. User stories capture what you need to develop, but now it’s time to knuckle down and dish out the work that needs to be done so that you can bring those user stories to life. In this chapter you’ll learn how to break your user stories into tasks, and how task estimates help you track your project from inception to completion. You’ll learn how to update your board, moving tasks from in progress to complete, to finally completing an entire user story. Along the way, you’ll handle and prioritize the inevitable unexpected work your customer will add to your plate.
Break user stories into tasks :
In the beginning, we have a project iSwoon and all the user stories are collected as well. According to those user stories, we use a 20-work-day iteration to break down into below big board (we will mentioned latter). And now our jobs is to break user stories into tasks.
- Your work is more granular than your user stories
Your user stories were for your user; they helped describe exactly what you software needed to do, from the customer’s perspective. But now that it’s time to start coding, you’ll probably need to look at these stories differently. Each story is really a collection of specific tasks, small bits of functionality that can combine to make up one single user story. A task specifies a piece of development work that needs to be carried out by one developer in order to construct part of a user story. Each task has a title so you can easily refer to it, a rough description that contains details about how the development of that task should be done, and an estimate.
Each task has its own estimate and—guess what—the best way to come up with those estimates is by playing planning poker again with your team.
- Do your tasks add up?
Did you notice a possible problem with your estimates? We’ve got a user story with an estimate, but now we’re adding new estimates to our tasks. What happens when the two sets of estimates don’t agree?
- Task estimates add confidence to user story estimates
Your user story estimates kept you in the right ballpark when you were planning your iterations, but tasks really add another level of detail specific to the actual coding you’ll do for a user story. In fact, it’s often best to break out tasks from your user stories right at the beginning of the estimation process, if you have time. This way you’ll add even more confidence to the plan that you give your customer. It’s always best to rely on the task estimates. Tasks describe the actual software development work that needs to be done and are far less of a guesstimate than a coarse-grained user story estimate.
- Plot just the work you have left
Remember that burn-down rate chart from Chapter 3? Here’s where it starts to help us track what’s going on in our project. Every time we do any work or review an estimate, we update our new estimates, and the time we have left, on our burn-down chart :
- Add your tasks to your board
You and your team are now almost ready to start working on your tasks, but first you need to update the big board on your wall. Add your task sticky notes to your user stories. and also add an In Progress and Complete section for tracking tasks and user stories :
Start working on your tasks :
It’s time to bring that burn-down rate back under control by getting started developing on your first user story. And, with small tasks, you can assign your team work in a sensible, trackable way :
- A task is only in progress when it’s IN PROGRESS
Now that everyone’s got some work to do, it’s time to move those task stickies off of user story cards, and onto the In Progress
area of your big board. But you only put tasks that are actually being worked on in the In Progress column—even if you already know who’ll be working on tasks yet to be tackled. Your board’s only as VALUABLE as it is ACCURATE
- What if I’m working on two things at once?
Not all tasks are best executed in isolation. Sometimes two tasks are related, and, because there is so much overlap, it’s actually more work to tackle one, and then the other separately. In these cases the most productive thing to do is work on those tasks at the same time...
Rules of Thumb :
- Your first standup meeting...
You’ve now got some tasks in progress, and so to keep everyone in the loop, while not taking up too much of their time, you conduct a quick standup meeting every day. Your daily standup meetings should :
- You have to track unplanned tasks
So far, your board has kept track of everything going on in your project. But what happens when somthing unplanned comes up? You have to track it, just like anything else. It affects your burn-down rate, the work you’re doing on user stories, and more...
Note :
You’ve been hit by the unexpected, but that’s part of software development. You can’t do everything, but you also can’t make the
choice about what takes priority. Remember, the customer sets priorities, not you. You need to deal with new tasks like customer demos, and the best way to do this is to ask the customer what takes priority. Give the customer a chance to make a considered decision by estimating the amount of work that the new task requires and explaining how that will affect the current schedule. Ultimately, the customer rules, so as long as they have all the information needed to make a choice, then you need to be prepared to go with their decision by reshuffling your
existing tasks and user stories to make room for the surprise work. Ultimately you need to keep your customer in the picture as to what is in and what is out. Adding new unplanned work is not the end of the world, but your customer needs to understand that the work has an impact, and then they can choose what that impact is.
- Unexpected tasks raise your burn-down rate
Unexpected task mean extra work. If the unexpected tasks can’t be pushed into another iteration, then they need to be factored into your board. All of this means that your burn-down rate is affected, and not in a good way...
- Velocity helps, but...
You’ve got more work thanks to some unexpected requirements from your customer, but didn’t you factor this in when you calculated your team’s
velocity? Unfortunately, velocity is there to help you gauge how fast your team performs, but it’s not there to handle unplanned tasks :
- Float—the “extra” days in your schedule—disappear quickly.
An employee’s car breaks down, someone has to go to the dentist, your daily standup meetings...those “extra” days disappear quickly. And remember, float is in work time, not actual time. So if your company gives an extra Friday off for great work, that’s three days of float lost because you are losing three developers for the whole day. So when unplanned tasks come up, you may be able to absorb some of the extra time, but velocity won’t take care of all of it.
Note :
- We have a lot to do...
You’re in a tough spot. Doing some refactoring work is going to cost you time now, but the hope is that it will save you time in the long run. In addition you have the new demo that you need to prepare for the iSwoon CEO...but we know EXACTLY where we stand :
Because you’re monitoring your project using your board you know right now that there are challenges ahead if you’re going to keep things on track. Compare this with the Big Bang “See you later, I’ll deliver something in 3 months” approach from Chapter 1.
With the Big Bang approach, you didn’t know you were in trouble until day 30, or even day 90! With your board and your burn-down rate you know immediately what you’re facing, and that gives you the edge to make the calls to keep your development heading towards success.
Note :
It’s time to go to work. User stories capture what you need to develop, but now it’s time to knuckle down and dish out the work that needs to be done so that you can bring those user stories to life. In this chapter you’ll learn how to break your user stories into tasks, and how task estimates help you track your project from inception to completion. You’ll learn how to update your board, moving tasks from in progress to complete, to finally completing an entire user story. Along the way, you’ll handle and prioritize the inevitable unexpected work your customer will add to your plate.
Break user stories into tasks :
In the beginning, we have a project iSwoon and all the user stories are collected as well. According to those user stories, we use a 20-work-day iteration to break down into below big board (we will mentioned latter). And now our jobs is to break user stories into tasks.
- Your work is more granular than your user stories
Your user stories were for your user; they helped describe exactly what you software needed to do, from the customer’s perspective. But now that it’s time to start coding, you’ll probably need to look at these stories differently. Each story is really a collection of specific tasks, small bits of functionality that can combine to make up one single user story. A task specifies a piece of development work that needs to be carried out by one developer in order to construct part of a user story. Each task has a title so you can easily refer to it, a rough description that contains details about how the development of that task should be done, and an estimate.
Each task has its own estimate and—guess what—the best way to come up with those estimates is by playing planning poker again with your team.
- Do your tasks add up?
Did you notice a possible problem with your estimates? We’ve got a user story with an estimate, but now we’re adding new estimates to our tasks. What happens when the two sets of estimates don’t agree?
- Task estimates add confidence to user story estimates
Your user story estimates kept you in the right ballpark when you were planning your iterations, but tasks really add another level of detail specific to the actual coding you’ll do for a user story. In fact, it’s often best to break out tasks from your user stories right at the beginning of the estimation process, if you have time. This way you’ll add even more confidence to the plan that you give your customer. It’s always best to rely on the task estimates. Tasks describe the actual software development work that needs to be done and are far less of a guesstimate than a coarse-grained user story estimate.
- Plot just the work you have left
Remember that burn-down rate chart from Chapter 3? Here’s where it starts to help us track what’s going on in our project. Every time we do any work or review an estimate, we update our new estimates, and the time we have left, on our burn-down chart :
- Add your tasks to your board
You and your team are now almost ready to start working on your tasks, but first you need to update the big board on your wall. Add your task sticky notes to your user stories. and also add an In Progress and Complete section for tracking tasks and user stories :
Start working on your tasks :
It’s time to bring that burn-down rate back under control by getting started developing on your first user story. And, with small tasks, you can assign your team work in a sensible, trackable way :
- A task is only in progress when it’s IN PROGRESS
Now that everyone’s got some work to do, it’s time to move those task stickies off of user story cards, and onto the In Progress
area of your big board. But you only put tasks that are actually being worked on in the In Progress column—even if you already know who’ll be working on tasks yet to be tackled. Your board’s only as VALUABLE as it is ACCURATE
- What if I’m working on two things at once?
Not all tasks are best executed in isolation. Sometimes two tasks are related, and, because there is so much overlap, it’s actually more work to tackle one, and then the other separately. In these cases the most productive thing to do is work on those tasks at the same time...
Rules of Thumb :
- Your first standup meeting...
You’ve now got some tasks in progress, and so to keep everyone in the loop, while not taking up too much of their time, you conduct a quick standup meeting every day. Your daily standup meetings should :
- You have to track unplanned tasks
So far, your board has kept track of everything going on in your project. But what happens when somthing unplanned comes up? You have to track it, just like anything else. It affects your burn-down rate, the work you’re doing on user stories, and more...
Note :
You’ve been hit by the unexpected, but that’s part of software development. You can’t do everything, but you also can’t make the
choice about what takes priority. Remember, the customer sets priorities, not you. You need to deal with new tasks like customer demos, and the best way to do this is to ask the customer what takes priority. Give the customer a chance to make a considered decision by estimating the amount of work that the new task requires and explaining how that will affect the current schedule. Ultimately, the customer rules, so as long as they have all the information needed to make a choice, then you need to be prepared to go with their decision by reshuffling your
existing tasks and user stories to make room for the surprise work. Ultimately you need to keep your customer in the picture as to what is in and what is out. Adding new unplanned work is not the end of the world, but your customer needs to understand that the work has an impact, and then they can choose what that impact is.
- Unexpected tasks raise your burn-down rate
Unexpected task mean extra work. If the unexpected tasks can’t be pushed into another iteration, then they need to be factored into your board. All of this means that your burn-down rate is affected, and not in a good way...
- Velocity helps, but...
You’ve got more work thanks to some unexpected requirements from your customer, but didn’t you factor this in when you calculated your team’s
velocity? Unfortunately, velocity is there to help you gauge how fast your team performs, but it’s not there to handle unplanned tasks :
- Float—the “extra” days in your schedule—disappear quickly.
An employee’s car breaks down, someone has to go to the dentist, your daily standup meetings...those “extra” days disappear quickly. And remember, float is in work time, not actual time. So if your company gives an extra Friday off for great work, that’s three days of float lost because you are losing three developers for the whole day. So when unplanned tasks come up, you may be able to absorb some of the extra time, but velocity won’t take care of all of it.
Note :
- We have a lot to do...
You’re in a tough spot. Doing some refactoring work is going to cost you time now, but the hope is that it will save you time in the long run. In addition you have the new demo that you need to prepare for the iSwoon CEO...but we know EXACTLY where we stand :
Because you’re monitoring your project using your board you know right now that there are challenges ahead if you’re going to keep things on track. Compare this with the Big Bang “See you later, I’ll deliver something in 3 months” approach from Chapter 1.
With the Big Bang approach, you didn’t know you were in trouble until day 30, or even day 90! With your board and your burn-down rate you know immediately what you’re facing, and that gives you the edge to make the calls to keep your development heading towards success.
Note :
This message was edited 21 times. Last update was at 28/04/2011 16:40:07
沒有留言:
張貼留言