Chapter 4. User Stories and Tasks: Getting to the real work
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.
Introducing iSwoon
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:
It’s time to get you and your team of developers working. Take each of the iSwoon user stories for Iteration 1 and assign each to a developer by drawing a line from the user story to the developer of your choice...
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.
Note
We already used this to get estimates for user stories in Chapter 2, and it works for tasks, too.
Now it’s your turn. Take the user story of creating a date and break it into tasks you think you and your team need to execute. Write one task down on each of the sticky notes, and don’t forget to add an estimate to each task.
Answers in Sharpen your pencil Solution.
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.
Break user stories into tasks to add CONFIDENCE to your estimates and your plan.
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
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.
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...
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.
Try to double-up tasks that are related to each other, or at least focus on roughly the same area of your software. The less thought involved in moving from one task to another, the faster that switch will be.
Try not to double-up on tasks that have large estimates. It’s not only difficult to stay focused on a long task, but you will be more confident estimating the work involved the shorter the task is.
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.
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.
Task 1: Create the Date class
Bob’s been busy creating the classes that bring the “Create a Date” user story to life, but he needs a hand. Here’s a UML class diagram that describes the design he’s come up with so far.
Relax
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.
Task 1: Creating dates
Note
A diagram that brings objects to life, showing how they work together to make an interaction happen
Let’s test out the Date and Event classes by bringing them to life on a sequence diagram. Finish the sequence diagram by adding the right method names to each interaction between objects so that you are creating and validating that a first date that has two events, going to a restaurant and seeing a movie.
Standup meeting: Day 5, end of Week 1...
Bob: Well, I finally got the date class finished with a little help, ran late by a day though...
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.
Standup meeting: Day 2, Week 2...
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...
What refactoring do you think Bob is talking about? Take the class hierarchy below and circle all the things that you think will need to change to accommodate a new OrderFlowers event.
How many classes did you have to touch to make Bob’s changes? ___________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
Are you happy with this design? Why or why not?
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
You were asked to take the class hierarchy below and circle all the places that you think will need to change to accommodate a new OrderFlowersEvent...
How many classes did you have to touch to make Bob’s changes? Five classes were changed or added to add just this one new type of event. First the “OrderFlowersEvent” class needed to be added, and then the method to order flowers on a date needed to be added to the Date class. Finally I had to update each of the different types of date to allow, or reject, the new type of event depending on whether it’s allowed on that date or not
Are you happy with this design? Why or why not?
Five classes being changed seems like a LOT when all I’m adding is ONE new event. What happens when I have to add, say, a dozen new types of event; is it always going to involve this much work?
__________________________________________________________________
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...
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...
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.
Note
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 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.
... but it may not be enough!
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.
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
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.
Get Head First Software Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
