Idea Transcript
More Next Blog»
Create Blog Sign In
Journey to Better @andrewrusling Working as an Agile Coach allows me to learn and grow on a daily basis. This is my chance to share some of that new found knowledge
WEDNESDAY, SEPTEMBER 26, 2012
POPULAR POSTS
Top tips for Retrospectives Tip: Change ‘Five Whys?’ to ‘Five What Caused that?’ “No problem can be solved from the same level of consciousness that created it.” Al...
The Three Keys to splitting User Stories effectively
Scrum Master Competencies The Scrum Master is a complex, challenging and rewarding role. Consequently they need to develop a broad range of competencies. A diverse sk... Iteration Manager to Iteration Leader Scrum Master to Scrum Leader Iteration Managers/Scrum Masters should not just be managing their team. They should be providing the...
Splitting Epics into Features is hard, splitting Features into User Stories is hard and splitting User Stories into smaller User Stories is hard. Of course it is easy to do any of those steps poorly, but we are talking about making effective splits. Effective in that the team is able to efficiently work together to continuously deliver something of value to the Product Owner. Effective in that product risk and project risk is being addressed, while maintaining a clear picture of the team’s progress. Effective in that the splits eventually result in User Stories that the team can tackle in a sprint, i.e. each User Story adheres to most of the INVEST principles. In my mind there are three keys to unlocking the door to effective splitting of User Stories.
Key One: Understanding Understanding is a critical key in getting teams to effectively split up User Stories. I am talking about refers to the whole team understanding the Big Picture, Business Benefit and Design. Understanding the Big Picture How does this User Story relate to the Feature and the Feature to the Epic? This is important because it allows the team to know which things they can defer, and knowing what can be deferred opens up plenty of options for splitting User Stories. There is more discussion of deferring things in ‘Key: Thinking Vertical’. To achieve understanding of the Big Picture it is essential that the team is involved in splitting the Epic into smaller Product Backlog Items, early in the Release Planning process ideally as it the Epic is being split into Features. If the team was not involved in splitting up the Epic from the beginning, the Product Owner should make sure that the team is aware of the big picture, probably by describing the relationship between the features to the Epic. Understand the Business Benefit The team should understand the business benefit that the Feature should deliver and how that contributes to the business benefit of the Epic. Understanding of the business benefit helps the team to make smart choices about how to split up the Feature. I have found that teams who do not understand the business benefit can end up making choices that unintentionally diminish those benefits. For example they may reduce the amount of error validation that is done, thinking that it is good way of keeping costs down. However, when the business benefit centres around an awesome user experience bringing customers back, this is a poor choice. In this case the reduced error handling may upset some users and hence the business benefit is also reduced.
Funnel Task Board helping agile teams deliver more Many agile and Scrum teams struggle to limit their work in progress. This results in task switching, delays and other wastes, overall redu... Agile Coach Competencies When thinking about how I could further improve my skills and knowledge as an Agile Coach, I came to the question of ‘How does an Agile Coa... Why agile teams should not use an electronic task board I often hear people expressing interest in moving to an electronic task board . This always concerns me. I see so many benefits in physical ... Top tips for Planning Poker Planning Poker is a simple exercise that delivers outstanding results when performed well. It can quickly lead the team to a shared underst...
SUBSCRIBE TO
Posts All Comments
LABELS
agile (33) scrum (33)
planning (10) scrum master (10) change (8) coach (8) coaching (8) feedback (8) iteration (7) team (7) Lean (6) leadership (6) sprint (6) estimation (5) retrospective (5) communication (4) continuous improvement (4) impediments (4) product owner (4) story (4) training (4) transition (4) user stories (4)
Understand the Design The design should be understood by all members of the team, at least at a high level. This does not necessitate a lot of design to exist, the important point is that everyone in the team can talk in a common language about the design choices they are making and of course how that relates to splitting up the User Stories. For example testers should be able to hold meaningful conversations with developers about testing impacts based on the design and its relationship to split of User Stories. Sharing a common understanding of the design allows all members of the team to contribute ideas for splitting User Stories, which leads to item four. Whole team understanding The whole team should have a shared understanding of the big picture, business benefit and design. This shared understanding ensures that everyone can be involved in splitting up the User Stories and doing so in a way that represents their concerns. i.e. Testers can ensure that the User Story is Testable. Whole team understanding also speeds up estimation and builds the team commitment to delivering the User Story.
BLOG ARCHIVE
Key Two: Thinking vertically Waterfall development generally builds up the product layer by layer, or component by component, this is what I call the horizontal approach.
2017 (3) 2016 (4) 2015 (2) 2014 (15) 2013 (13) t 2012 (14) t September (3) The Three Keys to splitting User Stories effective... The benefits of time Top tips for Retrospectives May (2) March (5) February (2) January (2)
Image 1: horizontal development, the blue items are units of work / poor User Stories
The downsides to his approach when used for agile development is that it builds up debt, unbalances the work amongst the team, deprives the team of early feedback, hides issues and hence hinders our ability to be agile. The key to addressing the issues of horizontal approach; is to think vertically, to think about delivering vertical slices. Building vertical slices means that each User Story builds a piece of each layer of the product, the User Story must adhere to the Definition of Done and deliver some business value or be a solid step* towards that value.
ABOUT ME
Andrew Rusling Follow
85
View my complete profile
LINKEDIN
LINKS
Twitter My reading list London Agile Discussions Group Agile Coaching Exchange FOLLOWERS
Image 2: vertical development, the blue items are units of work / User Stories
Usually the code that is delivered with each vertical slice is very small compared to what developers would have experienced with the horizontal approach. Some people struggle with this, as they feel that they are going slower than they have in the past. Of course this is true so it is important that we explain to them all of the benefits that come with this approach, such as:
GOOGLE+ FOLLOWERS
Andrew Rusling Add to circles
Finding issues early as hence fixing them for less cost Not building the bits that we thought we needed at the start but later find out we don’t need The ability to get fast feedback from our Product Owner, peers and customers Realistic reporting of our progress towards done Delivering value with each User Story, as opposed to delivering untested code 85 have me in circles
An important concept to get across to teams that are new to the vertical approach is; they can be ruthless about things that get deferred within the release time frame. Take the example of building a new GUI customer search for call centre operators that allows for complex ‘SQL like’ queries to be create, executed and stored. There is no way we would release it to our customers with poor performance, no error handling, a clunky user experience, or half of the fields missing. Yet all of those things are great items to split out as separate User Stories, provided they will be delivered within the Release Time-frame. *While I agree that User Stories should deliver some business value (The V from INVEST), I have found that by splitting up User Stories so that they are small enough to fit into a Sprint there are often times that the business value is not clear. At the Feature and/or Epic level it is clear what the business value is, and the User Story is clearly contributing towards that, but the User Story itself does not deliver much/if any value.
Key Three: Experience in splitting User Stories This is a classic catch 22, a bit of experience in splitting User Stories seems to make it much easier to split the next User Story and opens up the mind to new ways of splitting User Stories. This is where an Agile Coach can really help, by working with the team to split their first couple of User Stories hence breaking out of the catch 22. Another option is to run workshops on splitting User Stories that include practical exercises. The workshops that I have run are always well received and provide teams with that vital kick start to their experiences. For most developers that are new to agile, the vast majority of their experiences regarding splitting up work has been in splitting it horizontally. It is a hard habit to break out of thinking this way, again this is where an Agile Coach is very helpful; to show them new ways of thinking. This can be accomplished with a few hints, some probing questions and pressure for the team to stick to the Definition of Done, while delivering an increment of value. Additionally to support the team in thinking about different splitting approaches I like to provide them with cheat sheets and short articles that describe different splitting approaches. Here are some of my favourite articles and cheat sheets: Twenty ways to split Stories by Bill Wake - One page cheat sheet and blog with detailed explanation. Patterns for Splitting User Stories by Richard Lawrence - another cheat sheet and blog with detailed explanation. How you'll probably learn to split features by J. B. Rainsberger - explains the transition in thinking about splitting that occurs for many people. Story weight reduction kit by James Grenning.
Causal Loop Diagrams Thank you to Renae and Shane who helped me to find the answers to why our teams were struggling to split up Features into small User Stories. We found the answers by drawing a Causal Loop diagram together, you can find out more about Causal Loop diagrams in the book The Fifth Discipline by Peter M. Senge. If you are stuck on a complex problem, I highly recommend that you grab a couple of peers and get them to help you draw a Causal Loop Diagram about the problem.
Image 3: A snap shot of the Causal Loop Diagram that inspired this blog post.
Photo of keys by: mmarchin
Posted by Andrew Rusling at 9:57 PM
0 comments
Labels: agile, scrum, user story
FRIDAY, SEPTEMBER 21, 2012
The benefits of time
I recently learnt first-hand the benefit that time brings, by that I mean how time for people to think through ideas and try it for themselves is crucial to success. Usually when I give advice to someone, I spend a fair bit of my own time thinking about how they are progressing and generally worrying about the situation. My recent experience has shown that by do that I am doing myself a disservice. The experience was as follows; a couple of teams that I had been coaching were both in tough situations for different reasons which I will not go into. I gave both of their Scrum Masters a couple of pieces of advice regarding some practices to change. Normally this is where I would have spent the coming days stressing about their progress and thinking of contingency plans. However some rather big impacts occurred in my personal life and work was the last thing on my mind. When I returned to work, I was surprised to find that both teams had achieved solid success with the suggested changes, all with no stressing on my behalf. I should not have been surprised; these were two very capable teams lead by intelligent and effective Scrum Masters. What I took away from this event was that I need to allow more time for people to think about and trial new ideas before I check back in with them. In the mean time I can find other people and teams that I can help. As a personal mantra: Plant the seed, don’t stress, just sit back and wait. Photo by: Earls37a
Posted by Andrew Rusling at 6:45 AM
0 comments
Labels: coaching, feedback
SATURDAY, SEPTEMBER 8, 2012
Top tips for Retrospectives
TIP: CHANGE ‘FIVE WHYS?’ TO ‘FIVE WHAT CAUSED THAT?’ “No problem can be solved from the same level of consciousness that created it.” Albert Einstein
This quote is one of the many reasons why I am a big advocate of using the Five Whys techniques in Retrospectives. My experience shows me that finding and then fixing the root cause has a much longer lasting effect then fixing the reported problem (aka symptom). While the Five Whys technique is great; there a little twist that can make it even more effective for new teams. Teams are new to Retrospectives find it a big challenge to raise issues that they are used to ignoring or hiding. Creating an environment where they feel safe to bring up issues is critically important for the success of the Retrospective. ‘Why’ is a word that puts people into a defensive state of mind. As it focuses the respondent on their own involvement in the issue and hence, they are inclined to play down the issue for fear of making themselves look bad. Hence I prefer to phrase the Five Whys as the Five ‘What caused that?’ Using the word ‘what’ takes the focus off the respondent and lets them look at the issues that caused the symptom. This allows them to stay in a problem solving state of mind as opposed to a defensive state of mind. Lastly when looking at a tough problem, writing up the Five ‘What caused that’ items on a whiteboard as the team discusses the issue helps to give the discussion focus.
TIP: VALIDATE THE INPUT OF ALL ATTENDEES One of the most effective techniques for creating a safe environment in Retrospectives is a simple one; validate the input of all attendees, especially the quiet people. What I do to validate their input is summarised in these points: Validate each idea that is raised by either reading the idea aloud or repeat back the idea that was raised verbally. Treat all people and ideas equally (even if I strongly disagree) Keep the Retrospective to one conversation at a time so that everyone is involved in all of the discussions. Specifically ask quiet people what they think about issues under discussion. Support quiet people to get their ideas across when they do voluntarily speak up.
TIP: PRIORITISE AND CLUSTER The Retrospective format that I most often use is ‘Puzzle, Problem, Try, Keep’ from Agile Retrospectives by Esther Derby and Diana Larsen. Starting the Retrospective with five minutes for participants to write up their thoughts onto Post-it notes in silence is a method that allows everyone to provide their own unique input without being influenced by other participants. I suggest one thought per Post-It note, as it makes arranging and discussing each thought much easier. You can stick the Post-Its notes into the Puzzle column to begin with and it is usually a good idea to cluster similar thoughts.
Image 1: The teams ideas clustered in the Puzzle column by theme
With the initial thoughts clustered into the Puzzle column any important issues will stand out as a big clump. If you have lots of separate thoughts, it will be worth asking the team if there are any burning issues before proceeding. With the large clusters and burning issues identified you now have a set of thoughts to address first.
TIP: USE A WORKFLOW I see the ‘Puzzle, Problem, Try, Keep’ Retrospective as a workflow. Thoughts start out as Puzzles and either stay there or move to be a Problem. Problems link to Tries. Tries from previous Retrospectives were either successful and hence become a Keep, or need to be re-tried or are dropped. In general this results in a left to right workflow. After gathering the Thoughts of the participants into the Puzzle column it is always worthwhile discussing the Tries from the previous Retrospective. Was the Try successful and hence should become a Keep. Did the Try have issues that we think we can overcome; hence it stays as a Try. Is it an abject failure, hence dropping off all together? Discussing previous tries shows the team that Retrospectives are for delivering outcomes not just suggesting Tries that are never followed up on.
Image 2: The Try's from last Retrospective being reviewed and placed accordingly.
Now it is finally time to address the new thoughts. I suggest discussing each thought in turn. For puzzles and problems, use the ‘Five What Caused That?’ approach to identify the root cause, aka Problem. Once it is clear that you have a Problem move the Post-It to the Problem column and list the root cause.
Image 3: Put the top priority discussion topic into the Problem column and noting its root causes.
With a Problem in the Problem column that is well understood and it has a root cause identified it is time for the team to recommend one or more Tries. These are written in the Try column and you should draw arrows from the Problem to the matching Tries. The arrows represent cause and effect, ensuring that we put effort into Tries that will have some lasting impact.
Image 4: Linking the Problem to its Try's.
For thoughts about things that went well, or items you should keep; be sure to discuss with the team why it was successful and how we can ensure it will be successful again in the future.
TIP: FIND THE PROBLEM THAT TRIES ARE ATTEMPTING TO SOLVE Often participant’s thoughts will be suggestions for Tries, e.g. ‘Run the tests in parallel’, or ‘Use Gradle for our build process’. In this case it is very important to understand what Problem they are attempting to solve before just adding the Post-It note to the Try column. You can use the ‘Five What Caused That?’ approach to ensure that you attempting to solve the root cause.
Image 5: What the board could look like at the end of a Retrospective.
TIP: MAKE SURE TRIES ARE TURNED INTO ACTION I have seen several teams that where good at coming up with Tries, yet were poor at acting on those tries; hence they did not improve as fast as they could have. The reasons for the lack of action were many and varied. Here are a few of things that I have found to help teams follow through on their Tries. They can be used in isolation or in combination. Assign a single person as an Owner of each Try during the Retrospective. Display the list of Tries near the teams Task board. Create a Task cards for each Try and put it on the Task board. Discuss the progress of each Try during Daily Stand ups.
INTERESTED IN MORE TIPS? Top Tips for Planning Poker Top Tips for Project Retrospectives
Posted by Andrew Rusling at 2:47 PM
0 comments
Labels: change, cycle, discussion, feedback, group, impact, real change, retrospective, root cause, scrum, topic, try
Newer Posts
Home
Older Posts
Subscribe to: Posts (Atom)
Copyright © All Rights Reserved. Picture Window theme. Powered by Blogger.
View all