Posts tagged product backlog grooming
Walk the dog
Jun 10th
This is a simple technique with a marketing twist to its name. This title came to me while coaching a team that was struggling to behave cross functionally and were paralyzed at delivering working software at the end of their sprint. It is a simple mental discipline that I have often used in crafting good user stories and I wanted them to walk their user stories with me.
Everyone is not an expert at analyzing business requirements against technical complexity, but most have had practice walking a dog. So lets ‘walk the dog’, plus this is much cooler than ‘lets walk the user stories’.
Metaphors only go thus far, but a cool title goes much farther. For me, a fancy title, acts as a trigger that allows me to break from the ongoing chain of discussions and engage in an exploratory exercise.
I have used this technique a few times to address primarily two types of challenges, here are these stories:
Stories ‘not-done’ at the end of sprint:
This team was formed of team members that were experts at their part of the code. This was their second sprint as a team and they were struggling to cross-train. To their product owner’s credit, he was creating user stories that were truly vertical slices of functionality that represented end-to-end implementation of features. Their main challenge was that in their two week sprints they were unable to meet ‘definition of done’ (fully integrated & tested) on these user stories.
.
In response the team was asking the product owner to further split these user stories in two to three horizontal slices that could be integrated in later sprints. The product owner, was rightly pushing back since that would mean that none of his features would be developed end-to-end in a sprint. As their coach, while I was supportive of the Product Owner’s judgement, I was not sure whether I truly understood the team’s problem. I wanted to try an exercise of discovery with the group, and was concerned whether the group would allow for space and time to go with it.
.
So I christened ‘walk the dog’ technique. “sounds like its time to walk the dog” – I said.
‘Sounds cool’ said some one in the group, others looked perplexed and few others perked up.
.
So I asked the team to bring all their user stories from the current sprint. Starting with the first one, I asked them to walk me through the changes in code base that they will have to make in order to implement this story. I clarified that changes were considered only at the component level and not at the individual class file level. Then we picked another user story and did the same for that user story. At the end when we were done with all the user stories in the sprint, the picture looked like this.
Crude copy of white board diagram
We all stood back and after a few private moments of reflection, one of the teammembers asked why we are modifying on so many components in the same sprint? – bingo!
After this short diagraming exercise where the team literally walked each user story (the dog) through the changes in our components, the team was able to realize that the problem was not with the way user stories were split, but it was the lack of focus created by too many moving parts. The team was then able to rationalize why they were still trapped in their silo’s and why they were facing so many integration problems.
Earlier the team was asking the PO to split user stories along components so that they could manage complexity within their sprint. This exercise revealed another approach for the team. By limiting technical diversity for their in-sprint user stories the team was able to reduce complexity within their sprint and also deliver vertical slices of valuable functionality for their product owner.
Vertical Slices of functionality! – Not in my world
Another context where ‘Walk the dog’ was useful to me as a facilitation technique was when a team was locked into splitting stories horizontally across components.
Their architectural component environment was tremendously complex. Because of NDA’s with this client, I cannot reproduce their high level architectural diagram, but imagine a bunch of boxes interacting with each other. Some thing like this:
Their working context was further complicated. The team members were doing scrum and working on components A1, A2 and B. Other components X’s and Y’s were already developed by other projects. This is not to say that changes were not expected on component’s X & Y’s.
So we played ‘walk the dog’. This time however, I presented this technique as a game.
The Game:
Imagine that you have a pet dog and you are new in town. You take your dog to a park for a walk. You have never walked through this park but you have seen pictures and have seen the layout at the entrance to this park. Your objective is to enjoy your stroll through the park and get home before it gets dark.
The Park:
The actual diagram was printed and pasted next to a white board. Next we drew all the boxes (components) on the whiteboard and I purposely asked them not to draw connecting lines between the components. So the diagram on the white board looked like this:
The Dog:
Next we talked about end user functionality and picked a few functional cases.
The Walk:
We picked one end user functionality and charted its walk through all the components that would be affected.
Getting home before dark:
I then asked the team to do a quick round of planning poker style estimation, to decide whether this end-user functionality can be completed within one sprint.
In the case of our first end user functionality, the team quickly came to consensus that the end user functionality could not be delivered in one sprint.
We talked about why it is not possible to develop this slice of functionality. Over some conversation, it transpired no one in the team was confident that services exposed by component X2 will work. They said that although their platform teams have developed functionality that ‘should’ work for them, their prior experience with that group has not been good.
I asked ‘what if’ the component X2 worked as expected, would this end-user functionality still be unattainable at the end of a sprint?.
They said, there is no issue if the platform works as expected. We will be home with the dog before supper. No worries.
So for this particular end-user functionality, lack of knowledge about exposed services was the issue. Our conversations turned to how we can gain sufficient get-your-hands-dirty type learning. Reintroducing special story types such as research, spike & tracer bullets helped to stage a spike that will allow them validate functionality in their platform and deliver end user functionality for their sprints.
Same Park, New Dog:
Methodically we walked each end user functionality through the architectural component park. Along the way, we split many stories into thin slices of end to end functionality. This exercise resulted in a product backlog with enough vertically sliced user stories for the next 2-3 sprints. Valued byproduct of this was a list of immediate project risks, action items and shared understanding.
For this team’s case, the issue was not that they were technically unable to deliver vertical slices of functionality. It was their inability to work through organizational impediments. For them all external components represented a big department that had to be wrestled with.
Focusing on thin slices of functionality, exposing component uncertainties one at a time and a good walk in the park helped them reveal impediments. Prioritization of vertically sliced user stories by the PO helped the team and ScrumMaster to prioritize their impediments against the product backlog. Products developed in increments of features/functionality as opposed to the ones developed in increments of components allow for early realization of returns on product investment. Many teams resist this path since the overhead of dealing with all organizational impediments all at once often seem unsurmountable. This exercise helps reveal and prioritize these impediments. It takes courage and tenacity on part of the scrum team to then relentlessly pursue resolution of these organizational impediments – one at a time.
Recognizing Bottleneck's
Mar 24th
The term “bottleneck” refers to a point where after the flow or velocity perceptively reduces. It is metaphorically derived from flow of water through a narrow mouthed bottle where the flow of water is constrained by its neck. For drinking purposes it is a good thing as it regulates the flow of water through the bottle to the drinker, preventing wasteful spillage. Bottleneck’s though constraining can be both a good thing and a bad thing, depending on desirability from the system.
The scrum framework contains product backlog which is essentially a queue (stack ranked, one after the other) of product backlog items (PBI’s) that the scrum team has to complete. Queue’s/backlog’s don’t feel good. Think about the last time you were in a rush and had to go to a bank where you stood in a queue behind fifteen people before the teller addressed your needs. Or the time you had to stand in queue to board your daily commute bus – uncertain whether you will get a chance to board this bus before the driver declares “its full” and rides on. There is the frustration of waiting in a line and the uncertainty of whether you will make it. If PBI’s could feel, then I guess they would empathize with people stuck in queues.
IMO, inherent assumption within complex software product development efforts is that
the business will always have more concepts or requirements than the team’s capacity to transform these into potentially shippable product increments.
If this assumption holds true for you then your product backlog expresses the aggregate effect of bottlenecks that exists downstream in your system. In other words, if there were no bottlenecks or team had infinite capacity then the all the PBI’s will be transformed into potentially shippable product increments within a sprint. Velocity metric represents this constrained capacity of a scrum team. In scrum terms these bottlenecks and other blockers are commonly referred to as impediments. Impediments being a broad generic term, I’m focusing on bottlenecks – which are impediments that specifically cause reduction in flow at a systemic level over multiple sprints. (Nothing too revolutionary!)
Here are a few of such bottlenecks:
1. Ill-defined product backlog items
Top priority product backlog items are not well defined for the team to fill up at least their next sprint and start working.Too often this results in lengthy sprint planning meetings, and delay in terms of days before a scrum team makes sprint commitment and get going. In such cases the team spends the first few days of the sprint analyzing requirements, holding design sessions etc prior to making a sprint commitment. Sprints in this case go in fits and starts with a significant gap in software development efforts between the end of previous sprint and the start of new sprint. In this case the bottleneck is recognized as gaps between sprint end and start dates.
2. No product backlog items
In most cases, this situation is not an invalidation of the assumption that the business has more work than the team can do in a sprint. In fact too often the business has a pressing need to get many features out of the door. Flood of information, lack of agreement, “have to get it right the first time” has a paralyzing effect effectively boxing them in a state of limbo where PBI’s are not defined and the scrum team is left out to dry. Often the bottleneck in this case is upstream of the scrum development team causing either an abrupt end to sprint rhythm or a false start with frequently extended ‘sprint 0′.
3. Not-Done product backlog items within a sprint
It is common understanding that PBI’s within a sprint are either Done or Not-Done as measured against their definition of done. PBI’s that get Done are counted towards team’s sprint velocity and the rest don’t. Teams that end their sprints with some or many Not-Done PBI’s find that their ability to pull in new PBI’s next sprint is bottle-necked. Following the mechanics of good scrum practices these teams present Not-Done PBI’s to Product Owner and estimate remaining work for prioritization in Product Backlog. In my observations it is most likely occurrence that the Product Owner will ask for Not-Done PBI’s to be completed in following sprint. Effectively the team carries forward Not-Done PBI’s from last sprint into the next sprint. In cases like these, it may feel like that there is a smooth flow from concept to realization however it ain’t true. Look at the worst case scenario, no new PBI’s are pulled from product backlog and the team spends the next sprint finishing up not-done work from previous sprint. In this worst case example it is easy to call out such a bottleneck, in real teams there are variations along the continuum of getting all committed PBI’s Done to getting none of committed PBI’s Done. It takes an experienced scrum team and/or ScrumMaster to recognize this pattern while its happening for real.
4. Insufficient infrastructure
Lack of staging environments, insufficient QA infrastructure and/or production ready environments stops the flow of developed features at some point before these features can be deemed production ready or ‘potentially shippable’. All these features pile up and aggregate until a sprint or two prior to release date. Then the teams make a major ‘push’ to release all of the developed functionality out of the door.
These last sprints are often called as ‘stabilizing sprints’. And I have to say, I will start liking the term ‘Stabilizing sprint’ under the condition that all of the previous sprints are called destabilizing sprints. Each one of the previous sprints was destabilizing the product increment unpredictably. Sadly for me, most people interpret the term ‘Stabilizing Sprints’ as a good thing
.
Tricky thing with all the hard stuff, like performance testing, regression testing etc, that could not be done within regular sprints is that the hard stuff does not get simpler if its left for last sprint. It gets even more harder. Causing a snowball effect. Take regression testing for example, if regression testing was not done in previous sprints then in the last stabelizing sprint potentially a lot of regression bugs can show up. If these bugs cannot be fixed in the last stabelizing sprint, these will then ideally fuel addition of PBI’s in product backlog. Leading to either lower quality product release or a delayed release date. In either case, there in lack of objective perception regarding both quality and predictable release date. This bottleneck is obvious to everyone, for there are features piling up every sprint waiting to be production ready however the exponential negative impact is still underappreciated.
Barber Shop – Product Backlog grooming
Oct 20th
Most of us have to pay a visit to the scissor man/lady every couple of months. Others who don’t have to or choose not to, I envy you. As a kid, my visits to the barber shop were scary ritual. The thought of someone using scissors, clippers and other sharp pointed tools a few millimeters from my scalp and ears was terrifying. After surviving many close calls with sharp objects I was fairly certain that the worst that could happen would be a couple of cuts, minor scrapes and a hideous hair style. Over the years what gave me courage to go to our neighborhood barber shop was our barber’s technique/skill and relaxed friendly conversation that always ensued at his place. (That and my mom and lately my wife :).
I have not completely overcome my fear of visiting barbershops yet. There is always the possibility of getting bruised or a bad haircut. However I find it reassuring that it is in the nature of my fur to grow back and warrant another shot at presentable appearance. Scrum teams & PO’s that appreciate this emergent characteristic of product backlog find themselves engaging in healthy dialogue during backlog grooming sessions . As a coach, helping product owner & team to groom their backlog I seek to use tools and techniques that foster collaboration, allowing them to acknowledge the emergent nature of product backlog items. I have often found myself playing the role of that friendly neighborhood barber, armed and ready with agile tools to help product owners and teams groom their product backlog.
Collection of techniques
- User Story format: (As a [type of user] I want [some goal] so that [some reason])
- Three C’s (Card, Conversation and Confirmation)
- INVEST model
- Special story types – Research, Spike & Tracer bullet
Collection of Tools
- Index cards or Sticky Pads (lots of them)
- Sticky dots
- Sharpies
- Poker Planning cards
- Whiteboard/Flipcharts.
- Scissors
These are some tools & techniques that I find myself applying most frequently. The list above is a basic toolkit. (Good barbers always have a secret stash of innovative experimental contraptions, should the customer feel adventurous 
Application of tools and techniques during product backlog grooming is highly contextual and it largely depends on the nature of product backlog prior to grooming session, comfort level of product owner and team with grooming techniques and other external factors that indirectly influence the backlog grooming session.
A well functioning agile team grooms its product backlog, at least once, every sprint to build a professional product that sports stylish curls with hints of highlighting.
