Lisa Call

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.