Category Archives: Agile

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.

Happy, Sad, Ideas, Thanks – A Retrospective

2014-03-28 11.20.39

I’m lucky enough to be part of a team that are open and honest. That’s not to say there’s not room for improvement, but they’re open and honest enough to tell me that our retrospective format is becoming a little stale. In theory I should have known this already. Alarm bells should be ringing when the actions for improvement start to dry up. I could have abandoned retrospectives altogether claiming that the team couldn’t possibly improve any more. Instead I tried some new ways to get the team more engaged and varied the format a little. This week we tried the Happy, Sad, Ideas, Thanks format.

 

The Setup

Using a whiteboard, flip-chart or large piece of paper on the desk, divide the area into 4 with perpendicular lines. Label each quadrant happy, sad, ideas and thanks. To clarify these are:

  • Something that happened that made you happy.
  • Something that happened that made you sad.
  • Ideas you have to improve the process.
  • Thanks you want to give someone for something they did.

I asked the team to write stickies and place them in the relevant quadrant. The team generally know what things to write on the stickies but if your doing retrospectives for the first time you may want to place constraints around what is suitable offering examples as guidance. In this session I gave the team the freedom to add as many stickies as they wanted and did not specify any limits on each quadrant.

We then briefly went through each sticky on the board allowing the team to clarify what they meant and why they placed it in the given quadrant. This gives the team the opportunity to have a shared understanding of each of the points. At this point we didn’t go into too much detail and discussion, but just enough to know what each sticky was about.

 

Tailoring

There were a few things I tailored in this format to suit our team needs. Firstly, I asked the team to dot vote the stickies to ensure that the ones we talked about were the ones most important to the team. Depending on how much time you have and how many stickies you need to get through, you may want to do this. I then ordered each sticky in priority order within each quadrant.

As well as prioritising which ones were important to the team, this also allowed the team to get up and get moving around by adding their dots to the stickies creating any further clarification amongst the team that was not covered earlier.

2014-03-28 11.12.40

The other tailoring was excluding the ideas quadrant from the dot voting. The ideas I wanted to make sure we discussed so these were automatically put to the top of the priority list. The ideas quadrant give you your best chance at coming up with concrete actions to improve the process.

 

What went well?

The one part of this I really liked is the quadrant for saying “Thanks”. It is often assumed that this naturally happens amongst the team, and sometimes it does but this allows a great opportunity to give direct feedback to your peers and recognize them for something they have done. The recognition is a great way to encourage your team to say “Thanks” more often, but also to encourage the continued behaviour that led to the “Thanks”.

This format is easy to set-up and facilitate so makes it easy to run and is a great entry level retrospective, particularly for new teams who are beginning to discover their ability to inspect and adapt.

 

What didn’t go so well?

As a Scrum Master you always want to improve. This can often lead to focusing on the elements that they were sad about. In this session we spent some considerable time focusing in this quadrant only to find out that although the team were unhappy about these items their degree of unhappiness was on a scale. Had we evaluated this scale of unhappiness immediately we could have focused on other items for improvement.

The retrospective format itself didn’t bring about any devices that helped the Scrum Master get beneath the surface which meant that this was largely down to their experience. This will naturally depend on the teams (Agile) maturity so some guidance may be needed to focus the team on improving process rather than items such as “We made good progress on X”.

 

What would you improve?

As mentioned previously their are scales of emotions and I think its useful to gauge this in some way. This could be by asking the team to rate their scale of emotion between 1 and 10 on the stickies for happy and sad allowing you to discuss your discussions on the right areas.

If you find that the team are feeling particularly pessimistic or downtrodden and all the stickies are placed in the sad quadrant you or the team are struggling to generate ideas for improvement you may want to limit the number of stickies per quadrant forcing the team to think about each quadrant.

2014-03-28 12.10.36

Breaking the Kata cycle with Curiosity

Recently I came across Hakan Forss’s blog post on What is a Kata?

The following is an exert from this post:

“You learn and evolve a Kata through the three stages of the learning cycle Shu (learn), Ha (break) and Ri (create). In the first stage Shu, you learn by following the teacher. You imitate the teacher’s practices, values and thinking. You will only move on to the next stage when you have made the teacher’s Kata your own. In the Ha stage, you break from the teacher’s practices and make modifications based on your own creativity. In the Ri stage, you leave the teacher and you start creating your own unique Kata. As you expand your knowledge into new areas, you will loop back to the Shu stage for those areas in an ever-growing spiral of knowledge.”

http://www.bigvisible.com/2012/10/shuhari-agile-adoption-pattern/
http://www.bigvisible.com/2012/10/shuhari-agile-adoption-pattern/

The interesting part for me is “You will only move on to the next stage when you have made the teacher’s Kata your own”.
I recently came across a situation where eager engineers followed the frameworks set out by Scrum by the letter, sometimes using these guidelines as a stick to beat others over the head with when they were not followed. But like all frameworks and rules, there are always exceptions and they should never be blindly followed.

Although this shows great learning and knowledge of the process and makes you appear to serve the greater good of the customer, it does comes with pitfalls if you don’t have the curiosity. You may come across conflicts between those that want to follow the process because they are told it has value but don’t understand why and those who don’t follow the process because they don’t understand why they should.

It is often the latter that comes out as the agitator or the bad guy but this is not always the case. This behavior maybe demonstrating something you do want in your staff and illustrates an ability to progress through the 3 stages of learning.

Whenever you follow any process the curiosity inside you should always be asking “Why?”, leading to a true understanding. It is this step that should lead you to “break from the teacher’s practices and make modifications based on your own creativity”.

“Know the rules well, so you can break them effectively.” – Dalai Lama XIV

If you observe your team exhibiting this behavior, don’t always assume they are out to be obstructive. Ensure all your team understand why we perform the practices that we hold important.

No Resolutions just Goals

http://www.flickr.com/photos/katiedee/
http://www.flickr.com/photos/katiedee/

Recently my colleague Rob Lambert wrote about setting goals in his post A New Year – 2014 Goals. This is often a trend in the new year as many people make resolutions for themselves. Having thought through what a resolution is I came across this passage from Wikipedia which I really liked and will hopefully ring true to any of you who work in Agile teams.

 “…promise to do an act of self-improvement”

Sadly, more often than not, by this time of year people have often given up or are finding it increasingly hard to maintain their new promise for the year. But why do we seldom keep these resolutions or maintain these goals? At the time of writing there already recent posts such as Failed Your New Year’s Resolutions Already?

Is it that the goals are too unrealistic? or too vague?

What I do know is that changing our behaviors can be one of the most challenging things we can do as individuals and it often forces us to look into some of the foundations and ideals that we hold close, and that we live our lives by.

As a Scrum Master I recently went through this process in a training session and here’s how we tackled it:

What are you good at?

The most interesting point about this session was that we were asked to build on our strengths not our weaknesses. What naturally comes to mind when setting goals or resolutions is to focus on the things that we think we’re not doing so well at, however, this turned that thinking on its head. The theory behind this was that the changes we would be making would be far more rewarding as they were more likely to be successful as we already believed that we had some competence in these areas. As Dan and Chip Heath mention in their book Switch, the aim is to shrink the change. There is a far smaller gap between what we’re good at and where we want to be than what we’re not so good at.

Marking your own homework

As humans we’re intrinsically bad at self evaluation and in different ways this evaluation can have different biases. When it comes to goals and maintaining a specific behavior it is often the case that we make excuses for not doing something and take a very subjective view. Using someone else to monitor how you are doing gives you some objective feedback and also allows that person to generate idea’s and possibilities for why you did not achieve this. This does however require a certain amount of openness and honesty, something that we strive for in Agile and high performing teams.

In this situation we were asked to buddy-up with a colleague and each day review how we were doing with our habitual behaviors. This subtle but supportive approach gave pressure that you would not get individually and prevented you from being able to excuse your way out of not maintaining the behavior.

Focus on the Goals

When it comes to the new year there is no need for this to be a special time to set goals or resolutions, although sometimes a  compelling event produces this way of thinking. Resolutions are commitments and commitments are important as our facilitator Brindusa talks about in her post Commitment and winter holidays,

but I’m focused on my goals. Asking “what do I want to achieve?” is not necessarily defining how I get there giving me the flexibility to adapt and change my approach without fear of failure.

My Goals

One of my main goals for this year is to share my thoughts and learning’s through writing articles again. Although I have been doing this its mainly been internal to the company I work for. Previously I had failed at this endeavor so I’m using some of my learning’s to develop this new behavior. As we did in the training I need a buddy to provide supportive pressure and question when I’m not exhibiting my desired behavior……

….for this I’m counting on you.