Shared understanding - Why we size work

I think one area I get the greatest satisfaction as an agile coach is when I see a team really start to understand why we size things (rather than traditional estimating) in agile environments.  When I see the “ah ha” moment and the light bulb goes on it’s always a huge step in both their team formation as well as their understanding of some of the advantages of agile principles and practices.  They really start to understand the agile principle of communication over process.

It’s the discussion that allows us to come to a common size that really counts, not so much the number that we arrive at.  It’s the shared understanding of the business need and, from a lean perspective, what is enough to satisfy the business need and what is overkill.  Sure, having each of these items slotted into like sized piles is helpful for sprint planning, release planning, etc, but to me they are almost side benefits, and not the core benefit.

My favorite example.  Our product owner has asked us to provide a way to get across a waterway.  As team members, you might initially vote this as a 40, believing that we need to build the Golden Gate Bridge over the bay in San Francisco.

But I may vote it as a 2, because I think all we need is a log over a creek.

After we discuss the real business need with our PO, we settle on an 8 since we form a shared idea of building a simple bridge that still meets the business need.   The discussion required to arrive at this number brought out what the business really valued (provide a way for foot traffic to cross the creek) and the constraints involved (make it simple, yet attractive)  We now have a good idea of what done looks like (able to walk across the creek) and how to test it (allow up to 10 people at a time on the bridge)

It’s the power of these discussions that really brings the team into a unified vision of what business problems we are trying to solve, and a shared understanding of how we might solve those problems.  These discussions are what allows us to become more effective and efficient at saying if meeting this business value is bigger than a breadbox.

The All Too Missed reason for Scrum Standups

There is a non-stop parade of blogs and other instructional material on stand-ups.  What makes them effective?  And what are they REALLY for anyway?

Why do we have stand-ups?

The real reason for the Scrum Stand-up is to re-plan for the next business day what we need to do to achieve our sprint goals.  We come together to find out how far we got since the last stand-up (but not a status update!), what we learned from doing those activities, and what our direction and plan should be until the next stand-up.

What I did, what I’m going to do…

The three guidelines of the stand-up (what I did yesterday, what I will do today, any impediments) are in place to help us get to the right information as to what to re-plan.  What I did yesterday is only important to the rest of the team so as to illustrate what is completed and no longer an issue for us to meet our sprint goals, and to provide anything learned from those activities to get closer to or better at attaining those goals.  That's why it's not important that I only got one thing done yesterday because I had a ton of meetings (that will come in the impediments part); from a "How did I help move the team toward its goals" perspective, this is unimportant.  The fact that I was able to get a new test harness in place or confirmed the accuracy of a business rule we are building will really help the team in its re-planning efforts.  Sharing progress simply so that the other team members know what I accomplished (status update) is wasteful of the full groups time, since the team should be able to see actual progress from sprint boards and the like.  "What I plan to do today" is stated to share with the team what I think my role is in meeting the teams goals (till the next standup) should be.  However, as we re-plan, the team may elect to change my intended direction based on other impediments or changed direction.

Remember this diagram from Scrum training?  The "24 Hours" loop is the point at which we assess what we have completed, and what we should do next to keep moving towards the sprint goal.  This is the opportunity to apply the knowledge gained from the “what I got done” part to help the “what I will do” part.

The Impediment Factor

So now let’s talk about impediments.  Why should everyone else on the scrum team care that I have 3 meetings taking up my time, or am struggling with rebuilding that test harness?  They care because we are all pushing towards the same goals, and need everybody effectively pushing in the same direction to attain those goals.  Perhaps someone else that has bandwidth can take one of those meetings so that I can focus on the test harness.  Perhaps someone else has more experience and can help me with it, but then needs to offload what they had planned to another team member.  Maybe that test harness is no longer high priority and should be returned to the backlog?  Sharing impediments in a standup is a way of saying “I have these issues, what should we as a team do about them?”  The re-planning comes in to help us shuffle priorities for each team member, and possibly even for the sprint goals.

Why do we re-plan every day?

From the Scrum Guide from Scrum.org

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

We just spent 24 hours working towards a goal, the knowledge we gained during that time should help us re-plan, right?  This is the learning part of the do/learn/plan cycle that we go through each day in our effort to inspect and adapt.  We don’t wait until the sprint demos or the retrospective to adjust our direction; we do this on a daily basis.  Addressing impediments, re-planning based on what we learned, and adjusting the tasks involved in reaching that goal are all part of this re-planning process.

It’s the evolution of the ceremony

Scrum, as per the Scrum Guide, is

·         Lightweight

·         Simple to understand

·         Difficult to master

Advancing the Standup along its intended course of improvement from just answering the three questions to an evolved re-planning session is part of that “Simple to understand, Difficult to master” evolution.

Spikes – The Value of Information Gathering

User Stories have become the defacto standard in agile development to convey business needs to agile development teams.  There are countless posts and informative books and articles on how to write great user stories, but the essential statement of what a user story encompasses is to provide a short snippet of information that stimulates a conversation about adding value to the product.  Good user stories employ other attributes, such as valid acceptance criteria and following guidelines such as INVEST (Independent – Negotiable – Valuable – Estimatable – Small – Testable).

However, there is another type of story that is very useful: the Spike story.  A spike story is essentially a learning opportunity that we have discovered and want to explore.  The main difference between a spike and a user story is that where a user story adds value, a spike story answers a question.  Spikes allow us to do valuable work without necessarily adding direct (immediate) value to the product.  Spikes give us the ability to do research and knowledge gathering while including the needed constraints that a story framework provides. 

When to use Spikes?

Spikes are very useful in situations like the following:

Scenario I:  A user story has a well-defined business value, but we are unsure how to approach it.  For example, the user story calls for a particular grid capability on the user screen, but the team is unsure what the best technology is to accomplish this, and the outcome will influence the product owners view of the feature.  The team can create a spike story to create a working prototype for the PO to review to help define the feature and its acceptance criteria.  We can provide knowledge to the PO to help her/him see what is possible in creating business value, to be able to answer questions like “Is it realistic to have acceptance criteria that requires the ability to mix different data elements? “

Scenario 2:  The story is too complex, and we can’t find a way to break it into smaller business value chunks.  Can we solve some of the technical issues behind the story to reduce the complexity?  Can we do research on possible solutions to help reduce some of the uncertainty?  Let’s take our grid example from above, but what if the complexity comes from unknowns on how the new grid will perform with the current database technology.  Perhaps we can do a Spike on how the grid can consume the data in a performant way?

Scenario 3:  What if the PO has specified some business value, but the team has no clear idea on how to implement it?  This is another good usage of a spike, and can use techniques like A/B testing or beta tester feedback loops to determine the best way to move forward.  The team can use information from the PO on the vision of the feature, and experiment with different options to help further define that vision.

Keep it focused on value

One caution on using spikes: do not abandon the guidelines and constraints we apply to user stories.   Just because we are gathering information does not mean we can toss out the focus on business value.  Make sure that spikes still have a good title and description that define the conversation to take place.  Ensure that you are using the proper voicing in the story so that you maintain focus on who will be helped by this information.  Hint: it is common and acceptable to use the PO or team as the role needing the information, but avoid a specific role on the team, such as developer.  The entire team should be able to consume and learn from the knowledge gained.  Above all, make sure that you define and agree upon what “done” looks like in the form of good acceptance criteria.

By Example

Going back to our grid example, let’s see what a spike story might look like. 

Business Value: Give the user the best experience when merging their media files in their library.

Spike Story: As a product owner I want to learn about different ways to allow the user to merge media files in their library.

Acceptance Criteria: Verify I can review 2-3 options for merging the data.  Ensure that I can accurately compare the pros and cons between the different options. 

Note that the acceptance criteria does not specify being able to actually merge the data, since we are not trying to solve the user story, only the spike.  The important part is that we provide the knowledge in a consumable format.

Quest for Knowledge

One of my favorite facets of agile development is the importance of acquiring knowledge, and applying it to reach our goals.  This is evident in the agreement with our stakeholders to invest in this knowledge acquisition.  Spikes are the contracts we use to justify these explorations and discoveries. 
Donald Reinertsen discussed in his excellent book "The Principles of Product Development Flow" the principle of buying information.  "Information reduces uncertainty.  When we reduce the uncertainty of an economic outcome, we create economic value."  Columbus and crew went looking for a short cut to Asian spices (perceived economic value), but came back with the (re)discovery of a new world (unexpected, but far greater economic benefit).  Sometimes those investments return value we never saw coming.