How Scrum team benefits from Kanban practices
While discussing some struggles of Scrum team with my friend He Mian during his Kanban course recently, i realize that Scrum team can benefit from many Kanban practices.
There are 6 core practices defined in Kanban method. They are:
- Limit Work-in-progress
- Manage Flow
- Make Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally
Let's look through them to see how Scrum team or any team doing iterations can benefit from those Kanban practices.
Scrum team usually adopts some form of task boards to help coordinate their work in sprint. The key is to effectively inspect where we are so as to adapt accordingly. Visualization in Kanban goes deeper than usual task board. When the cycle time of your stories is still long (e.g. a week or more), the additional details expose problems earlier and help us adapt faster. Kanban uses more elements when visualizing, such as area, color, shape, number, etc. For example, the impediment could be visualized as attached note with different color on the story. This brings everybody's attention immediately.
Scrum limits WIP indirectly by iteration. It's recommended to work on one story at a time, however, it may not be viable with small size story (e.g. 2-3 days, 2-3 people) and big size team (e.g. 7-9 people). It is good practice to limit WIP further inside sprint, and visualize that by limiting the number of lanes for example. One argument against doing that may be the risks involved in not starting the work, considering that the goal is to complete them all by the end of the sprint. We shall take risk factors into account when prioritizing stories. By limiting WIP, we actually improve the chance of completing them all by the end of sprint.
When managing the progress, reminder of sprint goal is a good step forward, while focusing on flow provides more clear guidance. Anything that prevents flow becomes impediment.
Bottleneck is one common reason that prevents flow. In Kanban, a few ways are suggested to address those both in the short term and in the long term. For example, when testing becomes bottleneck, you may first consider removing any non-bottleneck work from those people who are testing; then, you may consider improving quality of the work flowing there by doing more developer tests; then, you may consider having developers help testing. Scrum team benefits from ideas of flow management.
By measuring cycle time - the time you start working on a story till the time you get the story done, you get insights from control chart and distribution chart on how to improve the flow in the long term.
The focus on managing flow is also reflected in the way that daily standup is done in Kanban. We walk through the board from right to left, story by story. This helps making more effective inspection and adaptation.
The Definition of Done (DoD) is one of the most important policies in Scrum. The Definition of Ready (DoR) gets popular in Scrum community, which is another policy. BTW, in practice those may lead to the wrong focus on handover from one group to another, but those could be and are achieved collaboratively in many contexts.
Many Scrum teams create and evolve their working agreement, which forms a dynamic set of processes and policies. Kanban points out more opportunities to make policies explicit, and they become areas for improvement. This fits well with the inspection and adaptation on process. Only when you understand how you do things now, can you improve further. The improvement involves the update of policies, which becomes the baseline of next improvement. Scrum teams benefit from treating working agreement as the carrier of continuous improvement. And the working agreement is visualized in the board.
There are 3 practices defined as feedback loops - daily standup, improvement kata and operational review. We have talked about daily standup in managing flow, and let's look at the other two.
Improvement kata is the daily improvement activity. I have been promoting the paring of manager and ScrumMaster on process improvement. Usually, they work together on removing impediments. The impediments may come from daily scrum or retrospective. Kanban measures flow, and provides the feedback with data. The data is systematic, and supplements well for the impediments. Operational review acts as feedback loop in large scale. The key again lies at the analysis of data.
In Scrum, two levels of feedback are built-in, daily and sprint. Daily feedback is provided through status sharing in daily scrum and sprint burndown. Sprint feedback is provided through conversation in sprint review and release burndown, as well as sprint retrospective. Comparing to metrics defined in Kanban, such as cycle time control chart and distribution chart, CFD, etc., those feedback in Scrum is more subjective. Scrum team benefits from integrating more data in the feedback loop. In particular, we shall consider gathering objective data in sprint retrospective to achieve more balanced view and better insights.
- Improve Collaboratively, Evolve Experimentally
The improvement practice in Kanban emphasizes using models and the scientific method. The requires more rigidity in our improvement activities. While it is one direction to improve retrospective through more effective facilitation so as to increase team engagement and promote ownership, it is another direction to improve retrospective through more rigid analysis and followup. I have seen teams applying PDCA in their retrospective and reaping solid benefits.
Even though flow and iteration are different concepts and practices, when we dive deep, we find that Scrum teams benefit from doing some Kanban practices.
- use visualization to help inspection
- limit WIP for flow
- use flow to guide adaptation
- improve on DoD, DoR and working agreement
- create feedback from data
- retrospective with data
Examples, Acceptance Criteria and Acceptance Tests
Acceptance criteria vs. Acceptance tests
Recently, i had an interesting discussion with my good friend Xu Yi. We discovered an interesting difference in our way of thinking about acceptance criteria and acceptance tests.
In his thinking, acceptance criteria and acceptance tests have one-to-many relationship; while in my thinking, acceptance criteria and acceptance tests have many-to-many relationship.
Let me illustrate with a story about "cancel reservation".
Acceptance criteria could be:
- cancel 1-day before travel begins
- charge 10% for normal user, while no charge for vip user
- email notice about success or failure
His list of Acceptance tests is something like this:
- fail when user tries to cancel on the same day as travel begins
- succeed when user tries to cancel 2-day before travel begins
- normal user is charged with 10% for successful cancellation
- vip user is not charged for successful cancellation
- email with success notice is sent for successful cancellation
- email with failure notice is sent for failed cancellation
My list of Acceptance tests is something like this:
- a normal user cancels a reservation 2-day before travel begins, succeeds with 10% charge, and success notice is sent
- a vip user cancels a reservation 2-day before travel begins, succeeds with no charge, and success notice is sent
- any user cancels a reservation on the same day as travel begins, fails and failure notice is sent
[note] the above tests are still not concrete enough, but this is not particularly relevant for this discussion.
He likes his flavor because that makes each test very focused, if it fails, it fails exactly one thing. I like my flavor because that makes each test a user task, it creates more understandable specification.
Then, the discussion went to what examples are, are they acceptance tests, acceptance criteria or something else? Examples are concrete, while acceptance criteria are more abstract rules. We tend to think that examples are not the same as acceptance criteria, while both examples and acceptance tests are concrete, thus they are more similar. Are they the same? If we ask users to give an example, they would usually not go to the granularity in Xu Yi's list, while possibly similar to the granularity in my list. From here, i realize that while we talk about examples, there are two different roles they play.
Examples as discovery vehicle
Examples are powerful vehicle for the discovery. In big discovery to creating stories, you tell customer journeys, while in small discovery to eliciting acceptance criteria, you tell stories. They both are examples. Starting from some examples, we apply heuristics or play "what about" to get variations and alternatives, then rules emerge, then more examples. We switch between abstract thing and concrete thing, and iterate for discovery. Examples in this context are not specification.
Examples as Acceptance tests
Eventually, examples are refined into specification, and they are also called Acceptance tests. There is some tradeoff during refinement. It is more understandable from business and user perspective once the granularity matches their natural size. It is easier to debug from development and testing perspective with smaller granularity. It is also possible to supplement very small thus very focused examples, as illustrated in Xu Yi's list, with more integrated big-picture examples.
In short, here's my current way of thinking about examples, acceptance criteria and acceptance tests. We start discovery from rough or un-refined concrete examples, derive abstract acceptance criteria from those, then, refine examples into acceptance tests, which are still concrete but refined ones.
The future of Project managers
As to this topic, I am only talking about project managers in software industry. Same thoughts may not apply in other industries.
Traditional project managers
There is traditionally contract game between business (or product or customer) and R&D (or IT or technology or vendor). In the beginning of the project, business and R&D negotiate a contract, then it is handed over to R&D, and R&D is held accountable for the delivery.
Project manager is usually located in R&D side, and he/she is responsible for the successful delivery of the contract. The success is usually defined as on time, scope and budget. The focus is on the output - the delivered features, rather than the outcome - the delivered value. Even today if you look at chaos report, it keeps the same assumption. Project is still considered successful as long as it is well delivered with those measures, even when nobody uses it after it is delivered. Therefore, traditional project managers are delivery focused.
Change from Agile
In Agile, business and R&D work together to optimize value. There is (or should be) no such thing called delivery success, but business success. Agile, Scrum in particular, holds business side accountable for the project success, which is measured by delivered value and ROI. Self-organizing team is focused on delivery and business collaborates with them to maximize value on sprint basis. With this setting, it makes no sense and is actually harmful to keep delivery-focused project managers.
The future of Project managers
While discussing with a few thoughtful PMO heads about the future of their team, two possibilities emerged.
Some project managers developed strong domain knowledge and network with business side after working in the industry for 10-20 years. If they can abandon traditional project management thinking (e.g. fixed scope, push team on short-term delivery, manage tasks for team) and adopt Agile thinking (e.g. value driven, support team to build high performance, enable team self-organization), they become good candidates for PO. From what i have experienced, the lack of good POs is one big constraint to adopt Scrum effectively. It is certainly valuable if some project managers could transform to good POs.
Traditional project manager has little overlapping responsibility as ScrumMaster, and their qualification is also quite different. It is actually misleading to call ScrumMaster as Agile project manager. However, some project managers are indeed very good at working with group. If they are open to practice Agile and gain experience, they become good candidates for ScrumMaster and even Agile coach. Remember that great ScrumMasters work beyond team coaching, they coach Product Owners and organizations too. Project managers often developed broad view, which helps them on coaching beyond teams.
I foresee that traditional delivery-focused project managers will become less and less relevant in the Agile world. On the other hand, i believe that great people can adapt well and sustain their value in a different way.
Empirical process control in Scrum
Scrum framework is based on empirical process control, i.e. you inspect and adapt to achieve the goal. In my CSM course, we do an exercise to relate empirical process control with events defined in Scrum framework. The below table is one typical outcome.
Information for Inspection
Example about Adaptation
- Why have this sprint?
- Story/task status
- Sprint burndown
- Add/remove/update tasks
- Change daily plan to work on different tasks or solve impediments
- Renegotiate on stories
- Sprint abnormal termination
Product goal (1)
- Release goal
- Product vision and roadmap
- Product increment
- Product backlog
- Release burndown
- Add/remove/update story in backlog
- Change priority
- Next sprint goal
- Update release plan
- Cancel the project
Process goal (2)
- What happened in the last sprint?
- Any data (sprint backlog, sprint burrndown, bugs, etc.)?
- What worked well?
- What can be improved?
- Improvement actions
- Update working agreement
- Expand DoD
- Try pair programming
- Setup CI server
- Product goal. If your release after multiple sprints, for each sprint, release goal guides your inspection and adaptation in each sprint. However, in some domains where you release in every sprint, or even daily, product vision and roadmap guides your sprint-by-sprint inspection and adaptation.
- Process goal. You may define your improvement vision for the next period (multiple sprints) by team envisioning workshop, assessment such as health check.
Explore PO team
PO (Product Owner) is defined as single person in Scrum. However, for various reasons, in practice a team may be formed to fulfill the role of PO. I am using the term of team rather freely, strictly speaking, some of them are only working groups. I'd like to explore different types of PO teams, and hopefully generate insights for you to use while designing your PO team.
Types of PO teams
Here's the main types of PO teams I have encountered.
This is probably not considered as a team, since it is normal that PO as a single person needs to collaborate with others such as domain experts, business stakeholders, and the development team. There is certainly team work here, however, to large extent, it is close to the surgical team described in "The Mythical Man-Month" book by Fred Brooks. I am now talking about the PO work - define the right product, not the whole product development.
In large-scale Scrum context, PO together with APOs (see details from LeSS introduction) form a PO team. This is similar to most management team. Each APO is accountable for its own area, meanwhile serving as team member in PO team. The PO is the leader of PO team.
In dual-track Scrum, product discovery is done by a team collaboratively - "the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items." It somewhat implies that product manager (or PO in Scrum) still leads the team, but the members work more interdependently as peers.
Value team, introduced by Ahmed Sidky in his Agile 2014 session, in many ways is similar to product discovery team. The composition of the team has a bit different focus. Value team seems accommodating more traditional roles, while i prefer the product focus in product discovery team. However, I view the emphasis of facilitator role in value team as an important addition. It highlights 3 important aspects regarding value team roles - ownership of vision, facilitation of team, accountability for results. I see that two of them (ownership of vision and accountability for results) belong to PO, while SM should facilitate value team (Ahmed has a different view on this). In this understanding, PO seems still taking somewhat leader role in value team.
New type of PO team
If we view discovery and delivery as two sides of product development, and now look at product discovery team and product delivery team, we may wonder why we define a leader for product discovery team, while we don't for product delivery team. If it is possible to have no leader in self-organizing delivery team (aka development team in Scrum), why don't we abandon the idea of defining one leader (i.e. PO) in discovery team? Instead, we create a self-organizing PO team without one defined leader. SM has the responsibility to coach PO in Scrum, while in this setup, SM facilitates and coaches the PO team (aka product discovery team, or value team), in addition to the development team.
Would the new type of PO team work well? This could certainly be controversial. I am listing a few points to trigger the debate.
- having one PO helps more efficient decision making, but efficient decision making is possible with self-organizing development team.
- product discovery is more divergent than product delivery, but there could be much divergence in finding architecture solutions too.
- there is often one leader behind successful products, but successful products where a group of people stand behind exist too.
- the cases of having group behind successful products are rarer and more accidental, but is it because there has been lack of facilitation and coaching in making the group work effectively?
- we need one person to interface with team, but why is it possible for PO to interface with development team (without leader), while not for development team to work with PO team (without PO as leader)?
If you experiment this type of PO team, I appreciate that you share back the experience.
Trust between PO and team
In my recent CSPO (Certified Scrum Product Owner) course, we had a discussion exercise about how PO breaks and/or gains trust from team. I'd like to share some points so that any PO can keep those in mind while working with the team.
How does PO break trust from team?
Team pulls the right amount of work into next sprint. When PO pushes team to commit, he breaks trust from team.
Sprint is closed to change, unless PO abnormally terminates it, which should be very rare. When PO regularly initiates change inside the sprint, he breaks trust from team.
- can't clarify the requirement
PO works with team to clarify the requirements. When PO takes requirements from somewhere with second-hand, and could not clarify questions or give examples, he breaks trust from team.
Even when PO can clarify what, but if he can not state why, he breaks trust from team.
- not available during the sprint
PO works with team not only during sprint planning and review, but also throughout the sprint. If PO treats himself as "customer", and disappears during the sprint, he breaks trust from team.
- no feedback for delivered features
After product increments are delivered, PO is supposed to collect the feedback from customers and users and share it with team. If team never hears back from PO about the delivered features, PO breaks trust from team.
If PO selectively shares back to team, with only good news, which demonstrates his good work in defining the product, while PO hides bad news and decisions he made earlier, which he feels embarrassing. When PO does this and team finds it out, PO breaks trust from team.
Team estimates size in planning. When PO does it for team, even says that it is just for their reference, he breaks trust from team.
- monitor the progress within the sprint
Team self-organizes to deliver the sprint goal, which includes monitoring the progress by themselves. Once team does that and micro-manages the progress within the sprint, he breaks trust from team.
Team decides how. If PO enters into the implementation domain and interferes team from self-organizing on how, he breaks trust from team.
Likewise, you may do the same exercise from team perspective. Here is some of my initial thoughts.
How does team break trust from PO?
Waterfall team often delivers partially done work by the end of the sprint. When that happens, PO has difficulty to know where we are and loses the flexibility to adapt in next sprint, team breaks trust from PO.
Team states that the work is done, while it is not. Later, PO finds it out. Team breaks trust from PO.
When team has many production defects after delivery or accumulates technical debts, their velocity on new features gets lower over time. Team breaks the trust from PO.
PO uses velocity for long-term planning. While velocity varies greatly, PO loses predictability. When team's velocity does not get stabilized after a while, team breaks trust from PO.
- not deliver the committed work
When team consistently delivers the committed work, it gains trust from PO. While software development has inherent uncertainty, if team regularly could not deliver the committed work, it breaks trust from PO.
On the contrary, if team overemphasize the safety in delivering their commitment, it does not set challenging goal for themselves, team breaks trust from PO.
- blame PO for requirement defects
Requirement clarification is a collaborative activity. When we receive requirement defects, instead of collaboratively seeking improvement, if team blames PO for those and runs away, it breaks trust from PO.
- do not support PO for backlog refinement
PO gets support from team in backlog refinement or product discovery. When team only focuses on the current sprint and leaves PO alone for future preparation, it breaks trust from PO.
I believe that you would come up with more ideas that will help PO and team gain and maintain trust from each other. Hope that these lists provide a useful start.
Experiments on Daily Scrum
The purpose of Daily Scrum is for team to inspect and adapt towards Sprint goal. The mechanics seem so simple, while in practice its purpose is often not well achieved. Here's some experiments that may help you find better mechanics to achieve purpose.
- Separate "inspection" and "adaptation" questions
If you look at 3 defined questions, "what did you do since last Daily Scrum?" and "what got in your way?" are questions to help team inspect; while "what will you do until next Daily Scrum?" is question to help team adapt. In typical Daily Scrum, every team member reports to each other with 3 questions in one round. I have found that it is more effective, as well as more natural, to do in two rounds. In the first round, everybody reports with 2 "inspection" questions, then, update sprint burndown and other information that helps understand where we are towards Sprint goal. In the second round, we focus on the "adaptation" question, which is essentially a daily planning or re-planning.
- Story focus rather than people focus
In traditional format of daily Scrum, people take turns to report. When the team is big (e.g. 7-8 people), and/or there are many ongoing stories (e.g. more than 3), it is hard to learn the big picture by listening to everybody reporting in round robin. The adaptation is rather accidental and individual oriented. It improves when you create story focus by reporting on stories in priority order. People working on the story report status and impediments, team as a whole adapts.
- Better focus by limiting WIP
When WIP (the number of ongoing stories) is high, it makes it hard to focus while inspecting and adapting. Inspection and adaptation become easier when you only look at small number of stories. You may physically create fewer lanes in your task board, and pull story only when there is empty lane.
- Sprint Burndown variants for better transparency
Sprint Burndown provides transparency for inspection. Traditionally, burndown is on tasks, everyday we re-estimate to get the remaining hours on tasks. Does it provide good transparency to help us understand how far we are towards our sprint goal? Does it incur much cost? You want to achieve best transparency with minimal cost, thus, teams experiment various burndown techniques.
- Some teams simplify this by not re-estimating tasks, but burndown only when task is done. This reduces the cost of re-estimating, and they find that the transparency doesn't suffer, instead, it is actually closer to reality because often the last 20% of task takes 80% of efforts.
- Some teams burndown stories. With the support of good engineering practices (continuous integration, ATDD, etc.), they are able to see the progress on story level within the sprint. This provides better transparency in the spirit of "working software is the primary measure of progress".
- Some teams think that the story granularity is still too coarse for progress tracking within the sprint. They burndown acceptance tests. While doing ATDD, they track passing acceptance tests as progress indicator, which is still based on working software.
ScrumMaster coaches team on inspection and adaption. GROW (Goal-Reality-Options-Will) is a simple coaching model for awareness and responsibility. "Goal" and "Reality" questions are great in helping team raise awareness during inspecting; while "Options" and "Will" questions are great in helping team take responsibility during adapting.
Keep the purpose of daily scrum in mind, experiment different mechanics to better achieve the purpose.
What change do you introduce next?
During Agile adoption and transformation, there's an important question of "what change do you introduce next".
I see a few approaches to introduce the next change.
- Adopt Scrum, which means to introduce Scrum roles - cross-functional team, PO and SM; Scrum events - planning, daily Scrum, review and retrospective; Scrum artifacts - product backlog, sprint backlog; most importantly, delivering Potential Shippable Product Increment (PSPI) in every sprint. This is a big and radical change. And it is just a starting place. By asking to deliver PSPI every sprint, Scrum acts as a mirror, exposing your problems and weaknesses, which you introduce your next change to address them. In short, it is the radical change (adopting Scrum) followed by incremental changes in the spirit of continuous improvement.
- Adopt Kanban, which means to introduce 3-6 practices. 3 practices are visualize the work, limit WIP and manage flow. 6 practices include explicit policies, feedback loops, improvement in addition to the 3 practices. This is a less radical change than Scrum, since it does not involve immediate structural change. Kanban is more a change management technique than a development process. By limiting WIP and measuring cycle time, it exposes your problems and weaknesses so that you can improve. Kanban evolves from lean thinking, and continuous improvement is its root. In short, it is a less radical change (adopting Kanban) followed by incremental changes.
- Adopt specific practices based on experience. Scrum and Kanban are explicit methods that group a set of practices for synergy, while experience based approach contains more tacit knowledge. In David Hussman's approach to create coaching plan, he assesses 4 areas - Team and community, Iterative delivery, Product and planning, Improving and tuning, then, based on experience, suggests the next change or set of changes. The change is practice oriented, rather than method oriented. For instance, if product and planning are weak, he may suggest to adopt practices such as Agile chartering, Persona and Story mapping; if iterative delivery is more restricting them, continuous integration may be the next change to introduce. This is followed by another assessment after a while, and another round of change, which is a continuous improvement cycle too. In short, it is incremental change after incremental change.
- As change, big or small, radical or incremental, they are really a continuum, rather than a dichotomy.
- One difference lies at the first step. Scrum takes bigger step than Kanban; experience based approach is flexible but usually takes smaller steps.
- Another difference lies at looking for the next change. Kanban and Scrum have built-in mechanism to guide your next change. Kanban has stronger focus and direction than Scrum on what to improve next. Experience based approach involves more tacit knowledge.
Path through Agile fluency
In 2012, James Shore and Diana Larsen created a team's path through Agile fluency.
- 1 star: focus on value by shifting team culture - adopting Scrum/Kanban practices
- 2 star: deliver value by shifting team skills - adopting XP practices
- 3 star: optimize value by shifting organizational structure - adopting product discovery practices such as lean startup
- 4 star: optimize for systems by shifting organizational culture - looking at culture of organizations such as Semco, Valve, etc.
In essence, Agile fluency model is an experience based approach. It creates explicit knowledge as a model based on authors' experience. As comparing to David's approach embedded in his coaching plan, I see two main differences.
- Agile fluency model contains more explicit knowledge than David's coaching plan. David only describes 4 areas that he would look into, which is explicit knowledge, while he doesn't explain how to come up with effective suggestions, which involves much tacit knowledge.
- The areas specified by David are in fact quite similar to areas in Agile fluency model. Team and Community vs. 1 star area; Iterative delivery vs. 2 star area; Product and planning vs. 3 star area. While Agile fluency model suggests the progression from area to area, David seems taking an approach to progress in depth in all areas.
In my experience of introducing changes, i have mainly been using the approach of starting with Scrum adoption. I realize more and more that many organizations are not ready for this approach, thus not effective in moving forward. I'm gradually taking more experience based approach in some context.
Considering "Limits to growth", i favor more on David's approach over Agile fluency path. However, we benefit from creating more explicit knowledge around areas.
- What's ideal in each area?
- What could be progression in those areas?
- Develop some checklists to guide the assessment and suggestions
I'll start on my own, talk to my colleagues at Odd-e, and talk to David about the interests to work together.
Recently, i attended a training on Kanban. To drive continuous improvement, Kanban has its main or even sole focus on shortening the lead time. I was impressed by results from a couple of case studies shared in the training. This triggered me to think further on how improvement is achieved in Scrum.
Before getting to improvement topic, let's first understand Scrum foundation a bit more. Scrum framework is based on empirical process control, which consists of transparency, inspection and adaptation. Transparency is necessary for your inspection and adaptation, moreover, goals make inspection and adaptation effective.
There are three explicit points for inspection and adaptation built in Scrum flow. They are daily scrum, sprint review and sprint retrospective. In CSM course, we relate empirical process control to Scrum flow. We start with the purpose of those meetings - they are all for inspection and adaptation. Then, we dive deep around the below questions - what goals guide inspection and adaptation? how frequent does inspection and adaptation happen? who's leading it? how do we create transparency? what information is inspected?
Let's elaborate on what goals guide inspection and adaptation.
- For Daily Scrum, it is sprint goal that guides inspection and adaptation. We inspect what happened in the last day and where we are towards sprint goal, then we make adaptation for the coming day.
- For Sprint review, it is product goal that guides inspection and adaptation. We inspect product increment from last sprint and where we are towards product goal, then we make adaptation about what to deliver in next sprint. The product goal is dependent on the context. In the context that you release in multiple sprints, it would be your release goals. In the context that you release every sprint or even continuously deliver your product increments, it would be your product vision and roadmap.
For Sprint retrospective, it should be process goal that guides inspection and adaptation. We inspect what worked well and what to do differently in the last sprint, then, we adapt by experimenting different ways of working in the next sprint. However, the inspection against goal is usually implicit and weak. I call process goal as improvement goal, since retrospective enables continuous improvement. What's the improvement goal? What does the perfection look like? Unfortunately, it's neither defined by Scrum, nor defined by most Scrum teams. The lack of improvement goals makes the inspection and adaptation in sprint retrospective often less effective than it could be.
In practice, the lack of improvement goals leads to lots of shotgun retrospectives. Teams randomly pick up problems to solve and areas to improve. We shall benefit from setting clear improvement goals. I'll share some ideas about what improvement goals could be.
First idea is to learn from Kanban. Lead time is probably the most leveraging point. We set the only improvement goal to shorten lead time. Less is more. We shall start to measure the current lead time and monitor its trend, then analyze and act on it for improvement. Kanban also provides specific tools for that, such as limiting WIP, CFD, control chart, etc. It seems a bit absolute and single-minded to only focusing on lead time, but it indeed has profound impact and will eventually cause improvement in many areas, such as collaboration, infrastructure, engineering practices, etc.
One challenge in using lead time as improvement goal in Scrum is that Scrum uses timebox. In theory, team may work on all items in parallel and get them all done by the end of Sprint, thus, the lead time for all items is the same as sprint length. In reality, this approach involves high risk and is discouraged. Once team tends to work on small items in sequence within the sprint, it could still be useful to look at lead time even if we do timebox.
Besides lead time, there are a few alternatives as improvement goals.
- When your definition of Done is still subset of what's required to be potentially shippable, expanding Done is an effective improvement goal. However, some companies are doing continuous delivery, which is already beyond Done at the end of sprint. For them, this is already reality, rather than improvement goal.
- Team visioning to come up with improvement goals for longer period of time, which guides sprint retrospective. Team radar exercise is a way to monitor its improvement progress.
- Velocity, which should be used with much caution. In a way, it's the equivalent of lead time in timebox. Through improving the flow, lead time will be shortened, while throughput will increase. However, since there's "easier" way to get improvement on velocity - by inflating the work size in story points, it is less effective than lead time itself in teams of creating real improvement focus.
In summary, establishing improvement goals is essential for the effective inspection and adaptation in sprint retrospective. It is worth looking at how Kanban drives improvement by relentlessly focusing on lead time.
When does story mapping help?
Recently, I attended a workshop by David Hussman, and story mapping was one of the topics. Since I had rarely used story mapping, while didn't realize its Indispensability, it made me think of why.
The introduction of story mapping technique is a response to lack of context for user stories. When you have many small stories, you lose the context and don't see the big picture. Those stories have to be combined to create complete user experience. The complete user experience is also called scenario or customer journey.
However, in my experience of developing telecom systems, i have never encountered this problem. To be honest, we seldom used user story, because telecom systems are not really user oriented and user intensive. We used to think in use case. When I compare story map with use case, the customer journeys in story map are similar to main success scenario and extensions in use case. Then, we simply take those customer journeys as PBIs (Problem Backlog Items) without splitting them into steps-based user stories.
- The process of writing user stories
When we work on user stories, it's common to brainstorm around user roles. Typically, we derive user stories from user tasks. Then, we find that some user tasks have to be combined in order to complete a journey. Therefore, story mapping becomes very useful, even necessary in order to understand the context and see the big picture.
- The process of writing use cases
However, if you write use cases, it starts with actors. More precisely, you start with primary actors and its goals. There is use case for each goal, and each variation for achieving the goal becomes main success scenario and extensions. You don't start with supporting actors, while the tasks done by supporting actors are necessary to achieve the goal, thus, they are pulled into the diagram.
- Change the process of writing user stories
If we apply use case thinking, we can modify the process of writing user stories a bit.
Think about primary users/personas, not every user who is interacting with the system.
Think about goals from primary users/personas, not tasks from them.
By doing this, you get stories to achieve goals, rather than stories to do tasks. In this case, those stories are scenarios and customer journeys.
- Examples for clarification
For scenarios and customer journeys in products and systems with rich user interaction, it is still beneficial to clarify by examples, where the scenario is clarified by listing all the tasks/steps it goes through. Those tasks could be initiated by primary user, but also from supporting users and systems. However, those tasks may not be, or preferred not, regarded as stories.
The other way to look at this is from story splitting. Take scenario based stories, if they are too big for delivery, we figure out how to split them. There are many splitting ways, with splitting from steps as one way, even not the recommended way, since those steps alone don't achieve user goal, thus, not really valuable.
So far, we compared story map with use case from its thinking process. Traditionally, use case mainly acts as a way to document the system, while user story and story map are mainly to support the communication. Story map is more visual and often exists in physical space, while use case is often written in document with UML notation. With Agile modeling, it doesn't have to be so, though.
It helped me understand story mapping and its implication by thinking this through, does it help you?