Lisa Call

My Taskboard on Oct 1

My Scrum Taskboard

In September I wrote several posts about using Scrum to manage my art career. In the last post I wrote about taskboards and explained how I was using it to track all the work I wanted to complete in September.

Quick refresher - the colored cards are the goals for the month (user stories) and there is 1 per row on the board. Each of the white cards are tasks that need to be completed for the bigger goals. The first column are tasks not yet started, the second column are tasks in progress and the final column are completed tasks. The colored cards on the right are goals I’m tracking but not actively working on.

Comparing the board from today from the board closer to the beginning of the month:

 
You can see I got a lot done. Certainly not everything but that big pile of cards in the completed pile indicates I did a heck of a lot art business and marketing this month. Probably the most focused and organized I’ve been in a long time, if not ever, for the business side of art.

This very visual indication of what I want to get done is a huge incentive for doing things. So I’m calling my first initial trial with scrum to be a big success.

Blocked Tasks

One thing I will add to my board is a 4th column. This is where I will put tasks that are blocked and in need of an external event for it to move forward. Such as waiting to hear from juried shows, or to get a return email, etc. I’d like a way to distinguish these tasks from the tasks I am actively working on (in column 2).

If a task is blocked for a long time it might mean I need to check in with the progress, or reevaluate the tasks and maybe find another solution.

Most of the goals (the colored cards along the right hand side of the board) are user stories where one of the tasks is currently blocked so once I add a new column these have a more natural home on the board.

Real Sprints

In scrum the goal is to put up on the taskboard only the work for a single sprint (I’m doing 1 month sprints). I obviously have much more work on my board than that so am not really sticking to that aspect of scrum.

There is a lot of value in seeing all (or at least most) of the work completed after a sprint completes so I’ll eventually get there but I’m not worried about it right now since my house is a big priority. We will hopefully begin building in a few weeks. I’m trying not to set too high of expectations during the building process.

Making Art in September

Although not managed through the scrum taskboard, september was a really good month in my studio also. One of my goals is to make art every day. Between work and kids and the house, it’s my escape and it helps keep me centered.

For September I worked in my studio 25 out of 30 days for a total of 55 hours. I completed 2 new pieces in my Structures series (#98 and #99) and made several small textile paintings.

Yay. That puts a smile on my face.

October Goals

So now it’s a new month and time to set new goals and maybe put some new goals/user stories up on my taskboard. I have some projects that ave been languishing on my todo list for months as I feel I’m still not quite caught up after moving in June. These are completed in October, I’m sure of it!

The first big goal for Oct will be to write and email my September studio newsletter. Then I’ll turn to a few misc tasks and then finally, I’ll tackle my website redesign project. I excited to get back to it.

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:

1. Get proposals and bids from 3 website designers for my new site.
2. Select designer.
3. Finalize design with website designer.
4. Approve completed work.
5. Tell the world about my completed website.

or

1. Install wordpress for new website design.
2. Design new template for website.
3. Create portfolio pages for website.
4. Create bio pages for website.
5. Create homepage for website
6. Flip the switch and make new website live.
7. 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.

 
Another post in my series on Scrum and My Art Business.

My last post I talked about User Stories. I was going to write about managing tasks in this post but realized I needed to cover some more basics first.

The Team

In a previous post I introduced the product owner as one of 3 roles in scrum. The other 2 roles are Scrum Master and Team Member.

Each scrum team typically has these members:

• 1 Product Owner - who writes the user stories, brings the vision for the product to the team and prioritizes the work to be done
• 1 Scrum Master - who gets rid of impediments that are stopping the team from getting their work done (more on this role later)
• 5-9 Team Members - who do the work. From design and architecture to coding and testing.

In my art business there is only 1 person to play all roles. The past month it’s been interesting to think about the difference between each of them. I find I excel at the product owner stuff of bringing vision and thinking up things to do. I’m less effective at actually doing it, not because I can’t, but because I get distracted. So I think I could be a better scrum master and keep myself on track better.

This weekend I unplugged my computer and removed it from my studio/bedroom - the result was 16 hours spent making art. Score one for the scrum master on that decision.

Iterate

One of the key features of scrum, and most agile software development processes, is that the work is divided up into iterations. A group of work is selected to be done for each of those iterations. In scrum those iterations are called sprints (because they had to come up with new words for everything).

Scrum is a series of sprints, typically anywhere from 2-4 weeks in length, that follow this structure

1. Planning Meeting - The teams select a set of stories to complete in the sprint.
2. The Sprint - The team works on those stories during the sprint.
3. Sprint Review - At the end of the sprint the team demonstrate the complete work to the product owner for approval.
4. Sprint Retrospective - The team holds a meeting to evaluate how the sprint went so they can adapt and do better next round.

Repeat these 4 steps over and over and over without end. Every once in a while the software is released to customers and developers move onto the next release with new functionality in the next sprint.

Planning

At the beginning of a sprint the team sits down and decides how much work they can do during that sprint. The stories are prioritized by the product owner, so the team selects the highest priority stories. Each story is also estimated in size. So the team picks the amount of work, based on the size of the stories, that they feel they can complete in the sprint.

Prioritization and Estimation are black arts in the world of software development and maybe not so different for an artist so I’ll touch on these topics again in future posts.

By doing the planning at the beginning of each sprint, instead of all of it up front at the beginning of the project, it is possible to make better informed decisions about planning as the project matures. It’s a fallacy to think the scope of a software project can be determined up front and locked into place. Scrum allows for a more natural way of planning and prioritizing the work.

I think this fits the needs for an art career well. As new opportunities arise and details of existing ones are made more clear, replanning each month allows an artist to reprioritize the importance of each of the goals.

I’m trying out some of these ideas and have decided on doing sprints of 1 calendar month. At the beginning of September I selected some user stories to work on for the month by looking through all of the work I wanted to do.

Sprinting

During the sprint the team members do the work to complete the user stories. They hold a daily meeting in which each member answers these questions:

1. What did I do today
2. What am I going to do tomorrow
3. What (if anything) is blocking me from doing my work

It is through these meetings, and the amazing power of peer pressure, that the team functions without an authoritarian model. If you had to stand up at work each day and be held accountable to your teammates for pulling your own weight, the theory is you will actually do your work, vs surf the internet and buy stuff from amazon and ebay.

I’ve mentioned before that I have an artist mastermind group that I email every night answering exactly these 3 questions. While we are not a team, in that we are working towards a common group vision, having to say to other people "err - didn’t do a darn thing - again" is huge motivation to keep on track.

I highly recommend this type of group activity. I found my mastermind partners during the Artist Breakthrough Program” I took with Alyson Stanfield last spring. We’ve been emailing almost daily for months now and I know for me personally it is huge.

The Review - And Done

At the end of the sprint the team demonstrates the software they completed. Only user stories that fit the definition of done are demonstrated (see my previous post on this topic of what done means.) Almost done or close to done don’t count.

The product owner looks at what the software does and decides yes or no if it is acceptable. How do they decide? It’s based on the acceptance criteria for the user story (see the section on testing in this post about users stories for details on acceptance criteria.) If the product owner either accepts or rejects the work.

Any story that is rejected or that does not fit the definition of done is moved back to the list of incomplete user stories and is placed in a future sprint during a planning meeting.

I’m about 1/3 of the way through my first art sprint so I can’t report on how this might look but I’m hoping I don’t reject too much of my own work as not good enough.

I’ve been doing planning in iterations for my art career for a while now, and again I use my mastermind group to keep me on track. I’ve tried weekly goals and 2 week goals and monthly goals. Again emailing to the other artists what I hope to do for the month and how that month went. So I’ll continue doing that as a part of my sprint reviews.

The Retrospective

The adaptive nature of scrum is a very important piece of the process so I’ll devote more time to this later also. If you aren’t thinking about how things went and changing behavior based on those observations you aren’t doing scrum. And really, you aren’t being very smart about life.

We’ve all heard the saying: the definition of insanity is doing the same thing over and over again and expecting different results.

It’s really rather obvious, but it’s also not so easy to implement.

The Rock

The photo at the top of this post has nothing to do with scrum but I like it so there it is. Another photo from hiking in Colorado. The water looks golden because of the pebbles underneath.

Click on the image for a larger picture and more rock details (I love rocks). It looks totally cool with my LED fancy screen on my laptop, which hasn’t yet been color calibrated so who knows what colors you might be seeing.

What Needs Done

The requirements for a software project are called user stories in the world of Scrum. These are basically a list of things that the software needs to do and they are written by the product owners, as I mentioned in my last scrum post.

User stories have a fairly specific format according to the Scrum powers that be, which is:

As a [insert person here]
I want [insert action person would like to take]
so that [insert benefit of action here].

For example, a user story for a user of a blog might be:

As a blog reader
I want to be able to leave a comment on a blog post
so that I can participate in the conversation.

This story tells the developer they need to provide a mechanism for readers to leave comments.

Art User Stories

The past few weeks I’ve been working on writing my art goals as user stories. Except not really. Because I see no reason to follow the above format.

The "as a" person is almost always me, the artist. So I skip that. And I am not looking to communicate between multiple people (in Scrum the product owner writes the stories and the developers need to understand them). I figure I understand myself fairly well so don’t worry about lots of extra words.

The "so that" benefit piece is important and if I see myself writing down a goal that has little to no benefit to me as an artist I question myself as to why I would want to do that item. Last month I ended up not entering 2 juried shows as I determined it was a large time drain with basically no tangible benefits to me.

Some examples of my user stories that I’ll be tackling in September:

• Complete setup of my new laptop
• September Studio Newsletter
• Complete rewrite of my website/blog
• Update artful home webpage
• Show my art at Butler Museum Show

Not quite as detailed as a software story but plenty of information there for me to know exactly what the thing is about.

Conversations

The description above is just 1 of 3 parts to a user story.

User stories are not complete and so they are a promise of a future conversation between the product owner and the developers [you will see this phrase a lot if you read much about user stories]. These conversations are the second part of a story. The constant feedback from the users of the system, represented by the product owner, is a key feature in making sure that the software that is delivered is what the users want.

For me as a solo artist I’m not going to be having conversations with myself about the stories (or at least not admitting that I talk to myself) but what this means to me is that I need to not get too hung up on some goals that maybe in the end aren’t what are best for my art career. I need to constantly adapt to the feedback I get from the market place and adjust my goals accordingly.

This adaptive feedback loop - plan - do - study - act (ie adapt) - is a key feature of scrum and it will come up several times. It’s also know as the Deming Cycle and makes for interesting reading.

Testing

The final part of a user story are acceptance criteria. How do I know when the story is completed, successful and done? I talked about done the other day. Each story needs to define what that means. When is the story Show my art at Butler Museum Show done? What makes it successful?

In the software world we write these things down as they are very important. Our quality engineers use these acceptance criteria to test the software and the developers use them to know that they are finished with the story.

In the art world I’m not writing this stuff down for the obvious things, at least right now. I think in the long run it might make sense to write these things down because how else do I know I’m done. For updating my artful home webpage - is it done when I’ve done the upload? Or after they have selected some work and put it on my page? Do I need to update my records as to which pieces they are displaying? To be clear, this information is best written down.

For the rewrite of my webpage the acceptance criteria is clear - the acceptance criteria is that I go live on both my blog and website with the new design. Anything short of that and it’s not done. (fixing bugs is a whole other story - but for now let’s assume there are none).

Tasks - Where are the Details

User stories tell the developer the What and the Why of a requirement. They don’t tell the How.

Writing down redesign website is all wonderful, but just how the heck do I go about this?

The answer is what most productivity folks say - you have to break down big stories and goals in to small manageable tasks. And that will be the subject of a future post as this is getting rather long.

Another post on my series on Scrum and how it relates to my art business. You can read all of the posts here: Scrum and Art.

Product Owners

There are 3 roles that people can play when they are on a Scrum team: Product Owner, Scrum Master and Team Member. All 3 of these roles apply to activities I do as an artist so I’ll cover them in differing amounts of detail. I feel the product owner role is a key role so I’ll probably talk about it the most.

A product owner is responsible for something called a Product Backlog in the scrum world. In simple terms this is a list of things, called user stories, that need to be done. In the software world this is the set of requirements of the system being implemented. The product owner creates the back log and, maybe more importantly, they prioritize the items on that back log. They are the ones with the vision for what the product should and could be.

Today I became a product owner for one of the scrum teams at work. As the former requirements engineer of the team, I got elected (and I agreed) that I would do well in this role, as writing user stories is a lot like writing requirements. Okay, actually it’s the same thing. The entire team will help out with prioritizing the list and the vision as we all have a vested interest in the outcome of this experiment.

The Artist as Product Owner

This role of product owner applies to me as an artist in couple of ways.

First with my art itself, I need to determine what type of artwork I want to make. Oil paintings? Textile paintings? Ceramic pigs? That’s all pretty straight forward and obvious that an artist needs to do this, although not always easy. Nor is it always simple to restrict ourselves to just one or even two mediums. Today I found my self hunting through the Denver Art Students’ League class schedule thinking about taking oil painting classes.

In addition to the art, I also need to define my art career business objectives and prioritize the activities. Should I blog or should I enter a juried show tonight? What is the ROI (return on investment) for each of these activities? How long will it take to do these activities? Should I have a facebook account? Should I sell my art on etsy? Should I make reproductions of my work?

Some of the aspects of scrum can help me figure all of this out. Or at least organize it in a way that will help me see what my options are. The first piece is to figure out what the art product backlog is - what are all the projects and business ideas that I have. For those that like the Getting Things Done lists - this is very similar to a project list, although with more detail so prioritization and estimation of the size of the job can be more easilty determined.

The other day I created a bunch of user stories for my art business, in the next post I’ll share info on the details of that activity and what goes into a user story.

Remodel Update

The builder has come up with a very cool design for my house. Scope creep (ie it’s getting bigger) is occurring again but hopefully not horribly so. It is by far the best design so I’m excited to see some plans soon.

A huge bonus will be I don’t have to move out of my house for them to do the remodel. I was not looking forward to moving out a few months after moving in. The last design, which I eventually rejected, involved picking up my house and setting it in the backyard to put in a basement. Hard to live in a house when that happens. The new idea is just a backyard addition, with some remodel work in the existing house to fix stuff in need of repair. Not as much entertainment, but more realistic.