Tasks
Structures #24 ©2003 32" x &23quot;
Today I finally get to breaking stories into tasks. [See all posts about here: Scrum and My Art Business.]
Tasks - The How
When I summarized the overall scrum process and sprints in my last post I didn’t give much information about how a team goes about completing the user stories. This post starts to address the nitty gritty on how that works.
A user story is a goal. In software the goal is stated as seen from the point of view of a user of the software. For example a user goal for amazon might be "I want to search for books about a given topic".
This is great for understanding what the software needs to do but it’s not much information for figuring out the day to day things a developer needs to do to make it happen. Developers need more technical details that explain how to go about doing something.
So the missing step that I glossed over in the last post was that during the planning meeting for a sprint the team breaks all of the user stories for the sprint into tasks. Small chunks of work that give the developers step by step tasks for getting the work done.
In simple terms:
A user story tells What and Why.
A task tells How.
From Stories to Tasks
Breaking the user stories down into tasks is not a simple process. In software, much of the design of the system is determined in how the work is broken down. Are there tasks to design a database? If so that must mean there is a database in the system.
The same is true when I think about breaking down my art goals into tasks. The user stories I wrote for my art business are big picture types of goals. They are what I want to get done and just like in softwware they aren’t telling me how to go about doing it.
One of my user stories is "Go Live on My New Website". This only tells me I want to redesign my website. It doesn’t tell me how to actually do it. There are several ways I can approach this - these are both reasonable task lists for this story:
- Get proposals and bids from 3 website designers for my new site.
- Select designer.
- Finalize design with website designer.
- Approve completed work.
- Tell the world about my completed website.
or
- Install wordpress for new website design.
- Design new template for website.
- Create portfolio pages for website.
- Create bio pages for website.
- Create homepage for website
- Flip the switch and make new website live.
- Tell the world about my completed website.
Which tasks are selected to complete a goal determine what type of work is really involved in a user story.
When Do I Have to Know How
There is no reason to know how to actually make a user story happen when it’s written. All I need is a dream or a goal and to write it down. Making it real and making it concrete by putting it in writing.
It’s too easy to forget my brilliant ideas so I try to write them down when I think of them. Now I have a great place to store my art business ideas. In my master list of user stories (which in scrum is called a product backlog, but "list of user stories" works for me). Jotting down ideas and adding them to this list is a great way to keep track of ideas.
When I reprioritize the list I can decide if it’s worth pursuing. The great thing is I don’t have to know how to actually do what I want to do when I write down the goal. I can figure that out later.
It’s only when it’s time to start working on a user story, ie it gets placed into a sprint, that I need to figure out the steps or tasks that will show me how to tackle the project. Than said, I believe spending some quality time working out the tasks is time well spent. A well thought out plan is never a bad idea. I try not to rush this step in planning.
Just Get Started
Some times a story is too large or unknown that I can’t figure out all the tasks. So I break it into pieces and only include the parts I know how to do. I leave the rest as something to figure out later. I might write a task that says: "figure out the rest of the tasks".
As long as I know at least 1 task to get me started that’s enough. The next step will become more obvious when I get the first completed. No knowing how to complete something is no reason not to make it a goal. I really want to quit my job and do art fulltime. To do that I need to sell my artwork.
So I spent some time thinking about the different ways I might want to sell my art and I made a user story around each one to try it out. I don’t know how to do some of them right now but I don’t have to. I can just get started on the ones I understand or at least identify the first step for a big unknown. With Scrum’s adaptive nature I can reevaluate my progress at any point and reprioritize my work.
What is a Good Task?
A few comments on what makes for a good task. In software it is a chunk of work that can be done by a single developer in a day or 2. For an art business it’s maybe not so clear. For me I feel a task needs to be something that I can do in a fairly short amount of time, maybe 3 or 4 hours at most but more often they are 1-2 hour tasks.
If a task is too large I sometimes find myself using it as an excuse not to do it. So I try not to make tasks that are way too big. I also find that tasks that are too small are really not worth writing down so I forget to do them, so I also try not to make things too granular.
I think some of this is personal preference. How much tolerance a person has for doing work without crossing something off a list or getting distracted.
Structures #24
Today I has happy to discover that I had never posted Structures #24 on my blog (or least I couldn’t find it). This made me happy because it gave me an image to include in this post.
This textile painting was the first piece I made after completing the work inspired by the Grand Canyon. While not officially part of that group, it sort of is. It’s maybe a cousin.
Next Scrum post will include some task management information.
Posted by Lisa in: Goals
Tagged: art business, goals, grand canyon, scrum, structures series, tasks, user stories









