Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Chris Sims on Sep 22, 2008
It is not uncommon for a scrum team to get to the end of the sprint and find that they have a story that has been worked on, but is not yet done. Perhaps the story appears to be about 80% done. What should become of such stories and how should the progress made on them be tracked? These are questions that every agile team will face. In a recent blog post, David Starr shares his approach.
One way to track progress is to give 80% of the point value of the story to the team for the current sprint. At first blush, this approach seems to accurately reflect the state of things, and may help keep the team's recorded velocity from varying up and down, sprint to sprint. It also has a certain amount 'feel good' value for the team. However, this approach has significant risk. The story is not verifiably done and the amount of time and effort that will be needed to get to 'done' isn't really known.
A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done. To the extent that some of the smaller stories are truly 'done', this can reduce the risk associated with the 'partial credit' approach. It also allows the product owner to make some decisions about the relative importance of the unfinished stories.
David finds all of the 'partial credit' approaches unsatisfactory and recommends that team be given no credit until the original story is fully completed. He recommends that the story be re-estimated and put back in the backlog. In David's words: "This model keeps things simple and keeps teams from gaming the numbers."
How does your team handle partially done stories? Post a comment and share what is working, and what isn't.
Learning to be a Good Product Owner: Foundation Skills
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
The biggest problem we have is not having sufficient 'done' criteria. I like the approach of taking an unfinished story and moving it to the next sprint. If it's not done according to your definition, the velocity is zero for that story in the current sprint.
A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done.
Why wouldn't you have split the story in the first place? You shouldn't just stop splitting when you think you have something that will fit into a single Sprint!
This is also something that is dependent on the length of a Sprint. The longer the Sprint, the higher the likelihood that something will not be completed, although that may sound counterintuitive. From what I've experienced, people are reasonably good at estimating smaller pieces of work, i.e. on the order of a few days to a week. The larger the work item, the lower the accuracy in the estimate. So, split the Stories until you can't split anymore without delivering value.
As for dealing with incomplete Stories, as always it depends. I do tell teams that they can't use the incomplete work against the previous Sprint's velocity, but they can revise the Story's estimate for the next Sprint if it makes sense to do so.
Dave Rooney
Mayford Technologies
Agile is about delivering value... this can't be obtained if the customer/user can't use the output of the story.
You wouldn't go into a restaurant and pay for a burger, and then accept the bun now and the burger and tomato in 10 minutes.
I discussed the >appropriate time to split a story on my blog.
In the review we let the product owner decide if the story is fully delivered, delivered with some work to be done or not delivered. Fully delivered or delivered with some work to be done gives all story points. If the story is not delivered no points are given. If the story is not fully delivered we write new stories that describe what needs to be done from the point where we are now.
What we do, is that during planing, the team splits each story into smaller tasks and assigns story points to each task. The tasks are usually 0,5 to 3 story points long and they represent a single piece of work (like creating one JSP). That way we always know how much of a story is left and we can include it in the planing of next sprint. If there was some work done on a task we either try to estimate how much work is left (in such short tasks it is very accurate) and include in the next sprint only the work left or we move the whole task in next sprint. This is what bests suits our team and fits best in our environment.
I don't think there is an easy answer to the problem at hand. In my experience, the most optimum solution depends on the following:
1. Which stories are unfinished (story complexity, story priority, impact on iteration, impact on release, impact on other stories)?
2. Where is the team in the release lifecycle (beginning, middle, end)?
3. Nature of the commercial contract with the client.
4. Client's willingness to engage in a "negotiation".
Various approaches I have tried and the lessons learned are:
<strong>Option 1</strong>: <em>Split the story into smaller stories and claim points for finished pieces</em>
My first question would be, why did the team not come up with smaller stories upfront? It is important to work with the team and understand if the team can do a better job of coming up with smaller stories upfront. With a team that is completely new to agile and has previously never been exposed to creating stories from requirements, a tendency to split stories towards the planned end of an iteration may be understandable but over a period of time, such occurrences should not happen at all.
<strong>Option 2</strong>: <em>Push an unfinished story into the next iteration (sprint)</em>
Most clients aren't happy about this since the instictive reaction it induces from a client is that the iteration milestone is being pushed out and will in turn push out the release milestone. Clients have usually made date and budget related commitments within their own organizations so obviously they won't like to communicate a delay within their organization. As a Project Manager, I always analyze the impact of changing iteration dates upon the release timelines before suggesting to a client that we push a story into the next iteration. We put some buffer into our estimates at the beginning so until the buffer gets used up fully, this approach usually works.
<strong>Option 3</strong>: <em>Extend the iteration until the story is finished. </em>
This is a slight variation on option 2 and some clients (usually those who are text-book agile fanatics) actually agree to this. The rationale behind using this option is to avoid calling an iteration as complete until every planned story is really complete. The challenges with this approach and the mitigation are similar to those for option 2.
<strong>Option 4</strong>: <em>Work extra hours to complete stories</em>
Sometimes we have to resort to this option, especially when the end of the release is near or when the team has ended up using all the buffer and we have no commercial coverage to minimize impact of a delay. I have seen teams that first adopt agile resort to this option by default. If however, teams do proper root-cause analysis to understand reasons for stories remaining unfinished, they can start using more and more of options 1, 2 and 3.
<strong>Option 5</strong>: <em>From the beginning keep buffer in story estimates</em>
Using theory of constraints for estimating stories, buffers can be introduced for stories that may be risky and for which accurate estimates cannot be provided upfront.
<strong>Option 6</strong>: <em>Introduce spike solutions before taking up technically risky stories</em>
Many times my teams have slipped on delivering a story because they hit a technical problem midway through implementing the story. In most cases, this has been because the team did not really analyze a story thoroughly at the beginning of the iteration and therefore failed to anticipate areas which may require further exploration. When starting an iteration I put special emphasis on uncovering potential pitfalls and problem areas. Then if required, we create spike stories for the current iteration and push out actual functional stories into future iterations.
In all cases except option 4, the client or the Product Owner is the final authority for approving the option to be exercised (may be obvious but stating anyway).
Even a 99% complete story which is not accepted or changed by the P.O. should not be accepted as complete. That defines what a complete story is: Something giving value to the product and which is shippable.
The estimation of how many story points to attributes to an incomplete story can be much harder. Answering this requires first defining what a velocity (in story points) measures, and what's the goal behind it.
I tend to have Story points measuring team production rate which mean how much (in size) can the team achieve in a Sprint. This is not a must but only a definition: You can define your own. This isn't the same as estimating how much feature have been added, because I exclude identified stories and changes found during the review. For that definition, an incomplete story having achieved 95% of the detail estimate, could get some story points but I'd rather give only a few.
The final goal is having an idea of how much can the team achieve (excluding again possible mis-communication with the P.O. and changes of mood or whatever changes the P.O. regularly has on the product backlog). By separating the varying elements (Product Backlog changes by the P.O., and the team velocity) I suppose the release estimations is more accurate.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply