Category Archives: Stories

Tasking Stories

I had an interesting conversation last week about what our teams perception of a task, story and chore are and the differences between them. This then led to a discussion around task breakdowns and whether these were necessary.

This got me thinking………I’d never even considered this before, breaking a user story down into tasks is all I know. It’s like I’ve grown up with it. I never like to do things just because that’s the way were always done, like in the Pot Roast Story, so this gave me the ideal opportunity to lend it some thought and consider why I think breaking down a User Story into tasks is important.

Sketch93183456

What is a task?

A task is a small unit of work that can be literally or theoretically sized between minutes and hours. (I won’t cover the pros and cons of sizing tasks in this post) The task falls at the bottom of the natural breakdown hierarchy

Tasks make up the smallest visible piece of the puzzle. It’s important to note here that tasks do not form any unit of business value, they are a list of practical things that need to be done in order to deliver the User Story as a unit of business value.

 

How does it fit into the Story process?

As the smallest piece tasks form the final piece in terms of identifiable work, therefore they often come at the last most point before work begins. This maybe at the iteration/sprint planning or may take place at a User Story kick off meeting immediately before the first task would begin.

 

Who does it have value for?

The mere existence of tasks has value for everyone immediately involved in the process including the developers, testers, scrum masters, product owners. This may also apply to any stakeholder depending on how close they are to the process. You may think that this is odd and that the User Story breakdown has no value for anyone other than the people working on the User Story, but there are 2 sides to this; the act of breaking down the User Story and the Visualization of this broken down work. Each side will have benefits to different sets of people.

 

Breaking down a User Story

The process of breaking your User Story down into tasks provides a collective and common understanding of the work that needs to be done. The discussion and review of the tasks can create further conversation on the scope of the work. If you choose to estimate tasks, whether or not you use that for planning or not, this may also give you an indication of how valid the estimation for your User Story was. This process add value for your team and the Scrum Master.

Tasks can also form non-code-specific items such as questions that need answering, assumptions that need validating or business as usual operations that you want to remind yourself to do as part of your delivery process. Tasks are a great way to achieve your definition of done. Without noting all of these things down whether they be on stickies or part of a check list they are a great way to make sure you have not forgotten anything.

 

Visualising your work

The second part of this process is visualising your work ( a key tenet in Kanban). By displaying your tasks in a visual way you are able to see the progress of the story as it moves through to completion. This is effective whether you’re using a Scrum Board or a Kanban Board.

The granularity of the tasks enables a Scrum Master to aid the team with their impediments and recognise bottlenecks without the need to rely solely on the teams feedback throughout the day. The board is always in the same place (hopefully) and your team as they move around and collaborate are not.

If you’re using physical boards and stickies the tasks also allow conversations to arise during the stand-ups where, just like index cards, team members can point, move or generally gesticulate at the specific items they want to talk about making it clearer to the rest of them team.

There are other ways of showing the progress of a User Story and maybe questions about whether people need this information at such a granular level, but on an information radiator this information is made available to all stakeholders and gives clear transparency whether they choose to use it or not.

Tasks are not compulsory by any means. They have some great benefits with little overhead and it works for me.

It’s not what you Scope but what you don’t Scope

The following post was originally published on an internal blog on Aug 15, 2013

“Music is the space between the notes. It’s not the notes you play; it’s the notes you don’t play.”
—Miles Davis

This quote came to mind recently when I was reading an article on the Agile Warrior blog. The post talks about a tool claimed to be developed at ThoughtWorks called the Inception Deck. This tool provides 10 questions to ask at the start of your project to set it up for success. Think of it as a process to gain clarity on why you’re doing the project when chartering and making sure you have the right people and objectives in place.

Although this tool maybe more applicable to an Epic or high level programme management there was one point that struck a chord with me and something which I think we overlook when planning a story in a Sprint.

Something I have seen reoccur are bugs being raised or Stories being rejected due to a confusion or a lack of cohesive thinking on what a feature should and should not do (Its Scope). We all approach the story definition with a range of assumptions and these assumptions are often around what the feature should and should not do and here in lies the challenge.

 

How do you remember to write down everything a feature should do?

One of the ways in which we can do this is by pining down the “Can Do’s” by defining the “Can’t Do’s”. By doing this we set a perimeter, defining the boundary, making it clear where the “can do’s” end and the “can’t do’s” begin. When we plan a story or define scope it’s not necessarily what the feature can and can’t do but what should and what should not be in scope. After all, if everything else is fixed, scope is the one thing that can be flexible. What aspects are you planning to change in the given piece of work? The Inception Deck describes this process as below.

 

Saying yes is easy. It’s saying no that is hard. The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project. Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow. Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.”

 

The idea is that you draw 2 circles, 1 for IN and 1 for OUT (of scope). During the discussion people pitch in elements of the feature that they think are relevant and you place them inside one of the circles. If there are area’s or elements that are unknown or are a risk you can place them outside of the circles as a reminder that these need to be followed up on.

Screenshot_2014-04-07-19-17-04

I thought this was quite powerful and useful for Story Kick Offs or Story Planning. I can remember times where we have wasted time replicating, repeating and raising bugs in area’s that we never meant to be changed and after a conversation around a pink sticky (for Story defects) on the board the following day, agreed that it was never in the scope of that story. This was clearly a form of waste which we could have prevented by communicating more clearly.

This aids in supporting Mike Cohn‘s 3 C’s of story writing:

  • Card
  • Conversation
  • Confirmation

The realms of what is not in scope are potentially infinite so there is still a level of assumption or rather common sense involved. However, writing this down and making it explicit appeared to be a much better communication of what we were setting out to achieve within a Story. If you decide to give this a go let me know how it turns out and what improvements or tweaks you made along the way to improve it.

Decisions

Recently I tweeted about my team.

 

DecisionsTweet

 

One of the common problems I see when writing user stories is the lack of definition. This definition needs to be at the right time, and there’s no hard and fast rule, and in the scenario below, this was at the story kick off, the last group chat before the coding starts on the story.

Previously the team when discussing our stories often felt that they got bogged down in the details. This is natural as the pressure to get stuff done and our sense of productivity means that we want to just get on with the task in hand. “If I’m not writing code, then I’m not being productive”.

After asking the team to try and be more thorough with the user stories as an experiment and reviewing the results in our retrospectives we realized the benefits that it had on the ability to deliver the feature quickly. With the first challenge completed we then faced out next challenge.

 

“I’m happy to write down in our acceptance criteria exactly what should happen when the user presses button X, but there are several options, which one is right?”

 

There are times when you might find your teams discussing at length which is the correct behavior. If this discussion starts to dominate a story planning or kick off meeting then its time to stop.

 

You Must Decide?

There’s no phone a friend on this one. The closet you may have is to ask the Product Owner, and that might be possible if they are in the planning with you, but does the Product Owner really know exactly what the customer wants from such a specific behavior? With any luck, they will be there to just make a decision, an often based on flipping a coin.

 

“Deferring a decision is deciding its not important.”

 

If your team relents on making these detailed decisions then gaps may appear in your product. If you don’t decide on the behavior of a feature, how do you know which is correct and which is not. This will ultimately result in a misunderstanding further down the line and cause re-work. If your lucky, this lack of definition will be caught by the testers in your team as they believed the feature should behave in a slightly different way, but still, this will be wasted time either discussing it after its been coded or re-work if you change your decision.

 

But What To Decide?

The stark reality is that you do not know what the right decision for this behavior is. The Product Owner does not know what the right decision for this behavior is. Some might even argue the customer does not know what the right decision for this behavior is (if asked).

The good news is, is that it doesn’t matter.

The paralysis and time spent discussing what is or what is not the right behavior and whether either decision has value to the customer is just waste. The best thing you can do is make a decision regardless of what that decision is. As long as everyone is agreed that a decision has been made. The time spent deciding on the decision is value wasted while your feature is not in production. The quickest way to validate whether the decision was right or wrong is by putting the behavior in a production or a per-production environment where real users can use it under real conditions.

The ability to do this quickly and shorten the feedback loop or PDCA cycle comes with techniques such as Continuous Delivery. The journey to Continually Delivering can be a long one with many challenges of its own, but even if your are only halfway there eliminating the waste of deliberating over small behaviors will be beneficial to both you and your users.