Tag Archive: Scrum


Backlog Refinement Meeting

Note:  This post was originally published on January 15. 2014, on AgileAtlas.org, a site of Scrum Alliance.  This site is now defunct.  Re-posting the article here.

Authors: Aashish Vaidya & Dorothy Murray

In Agile development, we engage in adaptive planning based on two of the 12 Agile Manifesto principles of “Welcome changing requirements, even late in development”; and “Regular adaptation to changing circumstance”.

Product Backlog Refinement is a core adaptive planning activity in Scrum.  Agile Planning is an ongoing activity throughout the project, not just one-time upfront activity done at the start of the project.  It is generally assumed that most team will have a Product Backlog that is not well defined, large and not finely grained.  The Product Backlog also doesn?t remain static, as new ideas flow in, as existing product needs are refined, new discoveries are made, and as priorities and business need change throughout the project timeframe.

Inadequately refined Product Backlog can result into many team issues such as:

  • Performing refinement during Sprint Planning leads to long, contentious meeting that blows past meeting time-box.
  • Sprinting on stories with great deal of ambiguity leads to unfinished stories and results into volatile team velocity
  • Work  is done on stories that have lesser business value, or are of lower priority
  • Delivery of user stories fails to meet desired functionality or fulfill stakeholder needs
  • Change of scope or priority during in-progress Sprint

Constant and incremental Backlog Refinement becomes a highly desired activity that a team must master to become more productive.  For newer and maturing Scrum teams, one effective way of perform Backlog Refinement is to conduct regular Product Backlog Refinement meetings outside of the Sprint Planning meeting.  Many Agilists recommend spending up to 5-10% of team?s time in planning future Sprints and Releases.   Over time, the need for formal meetings recedes as the team matures and is able to refine its backlog constantly and incrementally.

Generally, teams whose Sprint durations are from 2-4 weeks can benefit from conducting weekly meetings during non-Sprint Planning week(s).  For teams with 1-week Sprint duration, it may be more efficient to conduct refinement during Sprint Planning meeting itself.

The attendees to these meetings are those from the Development Team, but other subject matter experts, whose input is required or desired, should be invited as well.  Here are some additional pointers to consider in organizing Backlog Refinement Meetings:

  • ScrumMaster, in consultation with the Product Owner, organizes and facilitates the Refinement Meeting during non-Sprint Planning weeks.  We recommend the Refinement Meeting should be 1-2 hours per session.
  • Teams that don?t regularly refine their Backlogs should consider additional meeting time and higher meeting frequency.
  • Product Owner brings an ordered list of prospective stories for an upcoming Sprint.  Team reviews the list of stories, asks the product owner clarifying questions, refines the stories, acceptance criteria, and estimates un-estimated stories.  The goal is to have an ordered list of stories that are examined with the INVEST criteria and can be set to Ready to be worked on during the upcoming Sprint.

Outside of the regularly scheduled weekly Refinement meetings, a Team may also decide to have special, extended sessions to plan for subsequent Release or for some other type of mid planning horizon that extends beyond a single Sprint.  The rationale here is that it allows the Team and the Product Owner to refine a larger portion of their Product Backlog, and set up a workable Release roadmap.

A team can spend their time engaged in these activities:

  • Revising larger or coarsely defined stories into finer grain, well-defined stories for subsequent Sprints.  Consider merging other Product items together for better delivery preparation.
  • The Product Owner and the team engage in pruning and removing Backlog items that are no longer needed.
  • The Product Owner and the team add items that are newly identified and refine them and determine whether those are needed during upcoming Sprint or can be road-mapped into future Sprints.

The Scrum Core framework only asks that Backlog Refinement activity takes place.  But engaging in planned refinement meetings between Sprint and Release Planning sessions is one practical way for agile teams to achieve adaptive planning, and deliver on Sprint and Release objectives.

Advertisements

Note:  This post was originally published on November 22. 2013, on AgileAtlas.org, a site of Scrum Alliance.  This site is now defunct.

Authors: Aashish Vaidya & Dorothy Murray

Agile development is all about adapting to change. It is explicitly called out in the second principle behind the Agile Manifesto, “Welcome changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.” This is why, in Scrum, the Product Owner is responsible and accountable for maintaining the Product Backlog. The Product Owner has the final say over the ordering the list of ideas for a product. This includes selecting a smaller chunk of the Product Backlog as a Sprint Backlog. This gives the Product Owner, the lever on adapting to changing conditions.

The Sprint Backlog is the team’s forecast on completing work for the Sprint duration. It is expected that a team commits to reasonable amount of work based on its velocity and does everything within its power to deliver on these commitments. It is also expected that for the duration of the Sprint, the Product Owner or any other stakeholder is asked to maintain the Sprint Backlog constant. A team also is required to maintain its sprint duration constant so that it can deliver a product increment on a regular cadence.

However, under rare and extenuating circumstances, when a Product Owner or the team realizes that they cannot deliver on their stated Sprint goal, a Sprint has to be canceled or an Abnormal Termination of a Sprint is required.

Reasons for an Abnormal Sprint Termination may include, but are not limited to:

  • The company changes direction
  • Market forces render the work obsolete
  • A major technology change occurs
  • A better technical solution is found that makes the current Sprint’s activity throwaway work
  • Fundamental and urgent external changes that invalidate the Sprint Goal or the bulk of the functionality
  • Urgent bug fix or feature development request that cannot wait until the normal completion of the Sprint

Often times, Product Owners or other stakeholders interrupt teams and redirect them to new goals and priorities while a Sprint is underway. In many cases, this redirection isn’t due to critical needs that cannot wait, but it is because a Product Owner failed to think ahead. If redirection happens on a regular basis, a team will not develop cadence and produce high quality working product increment – the goal of every Sprint.

The act of formally canceling a Sprint makes visible the cost to all stakeholders, as there are overheads associated with stopping a in progress Sprint and in conducting another Sprint Planning meeting. Terminating the Sprint is a good way to ensure that the benefits of changing a Sprint backlog mid-Sprint really outweighs the cost.

The practice follows these general steps:

  1. Certainty by the agile team and product owner that the Sprint goal cannot be met or has changed significantly. The benefit of stopping work mid-Sprint outweighs the costs.
  2. Product Owner calls for Sprint to be abnormally terminated and makes this decision visible to all stakeholders.
  3. If there is critical emergency (such as production down), the agile team attends to the emergency.
  4. The team reflects on the reasons for the termination of Sprint, and plans on taking corrective action, if any are required, during next sprint.
  5. The Agile team and the Product Owner conduct a new Sprint Planning meeting.

Apart from legitimate but rare reasons, Abnormal Termination of Sprint is also a reminder, especially for transitioning organizations new to Agile practices, that every new request shouldn’t always be treated as an emergency.

Too Much Work in Process?

credit: Richard Smith via Flickr

Creative Commons  Credit: Richard Smith via Flickr

Does your team’s burndown chart look like one below, where a small number of stories accepted during the first part of the Sprint and then acceptance rate hockey sticks towards the end of the Sprint?  In the graph, you can see that acceptance rate is less than 10 story points (the green bar) for the first 14 days of a 21 days Sprint.  And then it gradually rises to 20 and rockets up in the last 3 days.  This graph  is for a Scrum team that follows a 3-week Sprint duration.

 

Iteration Burndown Chart

Iteration Burndown Chart

 

 

Or represented a different way, here is team’s cumulative flow diagram from the same Sprint.  Note, the team, within first 3 days of a 3-week Sprint, has put 46 out of 66 story points in play?

Cumulative Flow

Cumulative Flow

Does your team see any ill-effects with taking on too much work in process?  Does the testers on the team get squeezed trying to jam through 40-60 hours work effort into the last 1-2  Sprint days?  Are they compelled to make risk-based testing decisions?  Does your team, despite its best intention end up cutting corners by writing crappy code, carrying over defects and accumulating technical debt?

Does your team put in overtime to complete all the in-flight stories during the end of the Sprint?  During your story demonstrations, does your team leave your Product Owner disappointed, because it can’t accomodate simplest changes and force her to write new stories in the backlog to cover minor changes?

If your team activity resembles these charts, or encounters some of these symptoms, it is possible that it is taking on too much work in process (WiP).

 

Little’s Law and Queuing Theory

Let’s do a quick review of queuing theory and something called Little’s Law as formulated by John Little.  Little’s Law is expressed using a simple formula:

L = λW

Here,

L =average number of items in the queuing system,

W = average waiting time in the system for an item, and

λ =average number of items arriving per unit time

 

Sometimes, Little’s Law is also restated as: CT = WIP/TH.

Where, CT = λ = cycle time, for the average time when an item enters a system to the time it exists a system; WIP = L = work in process, the number of items in a queue and TH = W = throughput or the average output of a process.

It follows from this that the size of your queue is directly proportional to your throughput.

So, if you are trying to improve your cycle time, like how fast a story is accepted, then you have two options:

a)     Improve the throughput of your process/system

b)    Decrease the average number of stories you work on simultaneously (the WIP in the equation – the queue)

Typically, throughput is a measure of productivity and may largely depend on a team’s skillset or on the system the team operates in.  To make productivity or structural changes take time.  For example, a team might realize they can get more efficient by putting in place test automation and save time as compared to manual testing.  However, a team may not have anyone on the team with test automation skills.  So, it will need to acquire those skills, which means, a team member will need training, and then learn to implement test automation.  These activities take time.

Or say, your team needs to promote code to the staging environment as a part of your story acceptance criteria.  But, to promote code you need a deployment resource from the release team.  And if this resource is shared between few teams, as is typical, it would mean systemic wait time, till the resoruce is available to complete the task.  You can decrease this wait time by: 1) get a deployment resource dedicated to your team, who can do code promotion; 2) have a team member acquire those skills; or, 3) if you have someone with those skills on the team, lobby for changes to department policy that requires that only a deployment engineer can do deployments to staging environment.  To implement any of these  options will take some time to put in place.

So the best lever a team has, to decrease cycle time, is to decrease the average number of stories they work on at any given time.

 

 Why is Less WiP Better?

Queues are all around us: traffic during morning and evening commute, waiting for a restroom at a ballpark during half-time, a doctor’s office, waiting at a grocery checkout counter, and many more.  In lean terms, queues are considered inventory and inventory represents waste.  And I am sure when impateintly wait in a line, we can attest that it is a waste of time.

With Scrum, you are already working in delivering working software more frequently compared to traditional methods.  So, many Scrum teams may not even care that within the Sprint boundary, there is too much WiP.  Besides, Agile principle only states, “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”.  But, nowhere does it say, reduce your WiP even further.

Or it could also be that teams prefer higher WiP to provide them with that extra impetus to complete their work as the  Sprint-end deadline approaches.  Or a team doesn’t mind putting in extra overtime during the last week or last few days of the Sprint.

But, I suspect many teams and team members want to achieve realistic and sustainable pace in meeting their Sprint goals.  They are motivated in getting constant feedback with their business partners or POa by showing working software, early and often.  And they don’t want to systematically sucuumb to bad quality or crappy code.

As a matter of fact, Rally Software (Disclosure: I am Rally user), which conducted empirical analysis on teams and summarized their findings in The Impact of Agile Quantified (Note the paper is behind an free access wall).  They found that teams that aggressively control WiP, cut their time in process in half.  And those that control their WiP, have 4 times better quality compare to teams with the highest WiP.  So if faster feedback (or faster time to market) or higher quality is desired, it pays to lower your WiP.

But, note that there is an optimal WiP for your team.  If you push your WiP too low, you can lower your productivity.  It was found that teams with very low WiP (0-2 WiP) had lower throughput.  So there is certainly a balance that needs to be struck between too much and too little WiP.

 

Ways to Decrease WiP.

Generally, if your team uses some Agile Management software, they probably have a built in report that can show your team’s Cycle/Lead Time.  Once you know the Cycle/Lead time, you can start setting up targets to decrease the WiP.  So for example, if your team’s cycle time is 10 days, and your Sprint backlog is 10 stories.  Your team might decide to set a target of starting with only 5 stories, get them designed, analyzed, developed and tested.  Review the stories with the PO, get feedback, and get them accepted and move on to next set of stories.  This is the basic concept of Scrumban, melding the Kanban practice of controlling WiP within the Scrum framework.

In order to lower your WiP, each team will have to experiment to see what works best.  Here are some potential things to try:

  • Work with the PO to de-construct features into smaller stories during Backlog Refinement meetings so that they can be potentially completed within a week.
  • Set a team agreement on having only X number of stories in-progress.
  • Set general guidelines on how to “swarm” when team WiP limit is met.  For example, if WiP limits are met, an idle team member could: 1) help take up task on existing WiP story 2) pair up with someone to learn skills of a constraint skillset 3) Refactor code or test automation code 4) Swat down defects, 5) improve autoamted test coverage.  Have team members “swarm” on a few stories, instead of trying to put all work in play.

As you try to limit WiP, even with the above swarming guidelines, you will find that some team members might idle.  And it will feel counter-intutive.  But, you are not trying to achieve optimal efficiency at an individual level, but at a team level.  If you manage to lower WiP, the team will see that it cycle time is improved, quality is better, feedback loops are tighther,  there is less risk in meeting Sprint goals, and potentially a team will acheive more sustainable pace, experience less volatile team velocity.

Reduced to soundbites the lower WiP mantras are:

Don’t WiP it, Ship it.

Stop Starting, Start Finishing.

 

References:

Paper on Little’s Law with few examples:  http://web.mit.edu/sgraves/www/papers/Little’s%20Law-Published.pdf

Poppendieck, Tom and Mary, 2007, Implementing Lean Software Development: From Concept to Cash,  Addison-Wesley Professional.

 

Recently, an article that I co-wrote with my colleague, Dorothy Murray, on Abnormal Termination of a Sprint got published on the Agile Atlas.

The site is managed and curated by Ron Jeffries and Chet Hendrickson.  The site’s purpose is to become an encyclopedia of information about Agile and related methods.  Currently, the site is supported by Scrum Alliance.  So has more Scrum-centric information.  It is organized into Core Scrum, Common Practices and Commentaries.  The Core Scrum has Scrum Alliance sanctioned description of Scrum.

Our article got published as part of Common Practices, which are considered generally consistent with Scrum, and useful in many cases, but those that haven’t risen to Core status, yet.

(image from geograph.org.uk)

In one of my previous post titled You Might Not Be Agile If , I outlined some agile anti-patterns.  Recently, I come across couple of anti-patterns that make good fodder for discussion.  Both these patterns are something a Scrum Master should be able to avoid, corrrect.

Anti-Pattern: Only using partial team to size the backlog

 
The first one is where a team used only developers in sizing stories.  Well, is it any wonder then, that the team discovered itself in bind? Testing tasks turned out to be too large.  Surprised? The sprint committments got  jeopardized?  And is it suprising that team members ended up putting in extra hours to try and salvage the sprint?  In this particular instance, the reason was:  some team member felt the sprint planning sessions were getting too long.  So a select few team members pre-sized the backlog and tasked out the stories ahead of the planning meeting.
 
Now, there is a reason why we strive to construct cross-functional teams.  And we prefer using a consensus based estimation process such as planning poker.  We want to avoid, what some quant-driven companies have started calling –  HiPPOs hijacking and monopolizing the decision making process.  HiPPO stands for highly paid person’s opinion or alternatively, a highly positional person’s opinion. 
 
If a team lead, a Scrum Master, a Product Owner, a single team member, or a functional group “Hippos” the team, then that stunts the team from self-organizing.  You are back to command-and-control decision making structure and you miss out on the wisdom of the team – not very agile!  The planning poker or similar agile estimation process involves all team members, and it expects that all views and perspectives are allowed to be expressed, shared and discussed.  Two good things come out of the process, one is that you get a team members’ committment, not just compliance.  The other is that you get a much better and realistic view of your work, and you have intrinsically motivated agile team that owns the estimate and will do everything in its power to deliver on it.
 
But aren’t agile teams suppose to move fast?  Time-boxes are of course very important, but so is discipline.  If you don’t involved all team members, or if you short-change the consensus building process, you get uneven results.  What’s more involving the team allows it to gain tacit knowledge through meetings and conversations, which makes them better at getting things done.   
 
At the same time, agile teams are not deliberating, debating bodies.  They exist to produce great working software.  Reason given here was that the team wanted to have a shorter planning meeting.  So let’s talk about that.
 
The general rule of thumb that has worked for many teams is to allocate 1-2 hours per sprint week for the planning meeting.  Say you have a 3-week sprint, then normally your team should allocate anywhere from 4-6 hours of planning.  To make sprint planning go faster, there are few practices you can follow:
  • PO has already communicated her priority stories for the upcoming sprint during grooming sessions, which are taking place during off-planning weeks.  All prioritized stories are well understood and sized by all team members.
  • Most agile planning software allow you to copy a story.  So a good time saving practice is to create a “template” story which contained often encountered tasks.  The Scrum Master as part of his sprint planning session preparation can then copy this story, overlay the actual story card and the acceptance criteria.  This approach has another benefit too.  You can embed tasks associated with your story done criteria, which then serves as a good checklist for the team.  For example, if  your team forgets peer code review task on every story, then having an explicit task  as part of the template serves as a good reminder for the team to include for every story.
By the way, the team size matters too when it comes to having an efficient sprint planning meeting.  Having a goldilock-sized team of 7 (plus or minus 2), allows consensus building to occur without a huge time sink and makes for faster sprint planning.  I recall, a team that chose to go with 15 team members, their planning meetings used to drag out to almost two full days (14-16 hours) for a two week sprint!  How productive is that?!
 
Anit-Pattern # 2: Committing on more work than what can be delivered.
But is there maybe another deeper anti-pattern as a cause for this team that chose expediency over allocating “right” amount of time for sprint planning.  Could be that, they are trying to shove a whole lot more work than they can realistically take on during a sprint?.  (No time to waste, can’t you see, I have more code to shovel over to production, every day, so I will take any and all shortcuts possible, especially if I can avoid having uncomfortable conversation with my stakeholders!)
 
If that is really the issue, than there are good practices you can follow.  I have found that when doing capacity planning, it is better to start the team’s capacity at 80%.  So, if you have 14 working days (counting 1 sprint day towards demo, retrospective and planning meetings for a 3-week sprint), each team member will have , roughly, 90 working hours (14x8x0.8).  Using 80% capacity means that you do not have to account for tracking all the overhead minutiae such as company or team meetings, emails, water cooler chats, birthday celebrations, or just team members taking time to be helpful, or honing their own skills.  (An aside: this is also another reason, why I think it is a bad idea to use agile lifecycle management software for project time tracking.  It distracts from delivering good software and makes accountants out of team members).
 
Then, you subtract any “planned” PTO time.  Next comes any production support work that your team generally has to respond to.  The percentage varies from team to team.  Using a rolling 3 sprint average to even out the spikes as your starting point and adjusting according to your circumstances, works.  It is also a good practice to task out 1 or 2 more stories, over and above your team velocity.  So in case, you end up using less than your allocated production support capacity, you have a ready story to work on.
 
And finally, subtract any earmarks from your capacity.  For instance, many teams negotiate with their Product Owner and stakeholder, part of their capacity towards fixing defects, or doing test automation, or for code refactoring. 
 
If your team doesn’t account for all these things up front, you are probably operating on an illusion that you are going faster.  In reality, you are probably spending more and more time in remediating code and responding to production emergencies.  If you want to read more on this anti-pattern, check out Mark Lawler’s recent post called Sprint Planning Like It’s 1999
 
You say,  if I do all these things, there is no way, we are going to converge towards our project goals?  Maybe.  But, equipped with data, you may have a difficult, but an honest conversation with your stakeholders.  Should quality and delighting customers be sacrificed to meet the deadline, or should other creative solutions be explored?  Should we invest some time in building good software, or should we pay a whole lot more later?
%d bloggers like this: