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.
Welcome to iSwoon, soon to be the world’s finest desktop date planner! Here’s the big board, already loaded with user stories broken down into 20-work-day iterations:
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.
We already used this to get estimates for user stories in Chapter 2, and it works for tasks, too.
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.
Break user stories into tasks to add CONFIDENCE to your estimates and your plan.
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:
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:
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
If you want to know where you are on a project, you have to make sure your board reflects reality. If Mike is assigned to work on two tasks, but he’s only actually working on one, then only one task gets put up in the In Progress area. Otherwise, it looks like more is being worked on than really is.
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...
Sometimes working on both tasks at the same time IS the best option
When you have two tasks that are closely related. then it’s not really a problem to work on them both at the same time.
This is especially the case where the work completed in one task could inform decisions made in the work for another task. Rather than completing one task and starting the next, and then realizing that you need to do some work on the first task again, it is far more efficient to work both tasks at the same time.
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.
Mark: So, we’ve all had our tasks for one day now. How are we doing?
Bob: Well, I haven’t hit any big problems yet, so nothing new really to report.
Mark: That’s great. I’ve had a bit of success and finished up on the scripts to create tables in the database...
Laura: Things are still in progress on my user interface task.
Mark: OK, that all sounds good, I’ll update the board and move my task into Completed. We can update the burn rate, too; maybe we’re making up for some of that time we lost earlier. Any other successes or issues to report?
Bob: Well, I guess I should probably mention that I’m finding creating the right Date class a little tricky...
Mark: That’s fine. I’m really glad you brought it up, though. That’s a two-day task and we need it done tomorrow, so I’ll get you some help on that as soon as possible. OK, it’s been about seven minutes, I think we’re done here...
Your daily standup meetings should:
Track your progress. Get everyone’s input about how things are going.
Update your burn-down rate. It’s a new day so you need to update your burndown rate to see how things are going.
Update tasks. If a task is completed then it’s time to move it over into the Completed area and check those days off of your burn-down rate.
Talk about what happened yesterday and what’s going to happen today. Bring up any successes that happened since yesterday’s standup meeting and make sure everyone knows what they’re doing today.
Bring up any issues. The standup meeting is not a place to be shy, so encourage everyone to bring up any problems they’ve encountered so that you all as a team can start to fix those problems.
Last between 5 and 15 minutes. Keep things brief and focused on the short-term tasks at hand.
A daily standup meeting should keep everyone motivated, keep your board up-to-date, and highlight any problems early.
It’s okay if you’ve never seen UML before!
Don’t worry if you don’t know your UML class diagrams from your sequences; there’s a short overview in Appendix i to help you get comfortable with UML notation as quickly as possible.
Laura: That’s OK, this time around. We can hopefully make some of that time up later.
Mark: All work on the database is now done; I’m all set for the next set of tasks.
Laura: Great, and I got my work done on the user interface pieces, so we’ve actually got something running.
Bob: Always a good week when you head out of the office with something working...
Laura: Absolutely. OK, it’s time to update the board and our burn-down rate to get things set up for next week.
Standup meetings keep your peers, employees, and managers up to date, and keep your finger on the pulse of how your development work is going.
Laura: How are you going to do that?
Bob: Well, if you treat someone ordering flowers as just another type of event, then we can add it straight into our current class tree, and that should save us some time in the long run.
Laura: That’s sounds good. What do you think, Mark?
Mark: I don’t see any problems right now...
Bob: Apart from it might take an extra day right now to make the changes, but in the long run this should save us some time.
Laura: Mmm. We’re still a little behind, but we can probably lose a day on the burn-down rate now if it saves us time later on in the iteration. OK, I’m sold, let’s go for it...
Laura: Hey, isn’t “Buy jewelry” coming down the line? That works as just another event, too, right?
Bob: Yeah, but we’ll need to add some time to make those changes to all the classes again.
Mark: Can’t we come up with a more flexible design, so we can avoid this pain and effort each time we add a new event?
Bob: That’s exactly what I was thinking.
Laura: But that will take even more time, right? I guess we’re invested, though, huh? This will save us time later, I hope...
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...
Let’s take a look at a part of the board we haven’t used yet:
An unplanned task is STILL a task. It has to be tracked, put in progress, completed, and included in the burn-down rate just like EVERY OTHER TASK you have.
Yes, you’ve heard it before, but talking to the customer is the answer to most scheduling- and deadline-related problems.
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 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...
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.
Velocity is NOT a substitute for good estimation; it’s a way of factoring in the real-world performance of you and your team.
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....
Successful software development is about knowing where you are.
With an understanding of your progress and challenges, you can keep your customer in the loop, and deliver software when it’s needed.
You know there are challenges, NOW.
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.
All is far from lost! We’ll tackle all these problems in Chapter 5, when we dig deeper into good class and application design, and handle the customer demo.