I was recently emailed a question asking whether the sprint planning meeting should start with time allocated for putting story point estimates on any user stories that have not yet been estimated.
No, I don’t think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that:
- the product backlog can be prioritized. It is impossible to fully prioritize a set of items without knowing at least their relative cost.
- we can make high-level forecasts about how much will be done by when
- we can make tradeoff decisions between scope and schedule
We can achieve these goals with approximate, relative estimates such as given by story points. For example, if I decide to buy a new car this weekend it is sufficient for me to know that I can get a Toyota or Honda for around $30,000 and that a Ferrari goes for closer to $800,000. I do not need to know a more precise cost of the Honda ($31,850) before knowing it should be on my short list of cars to evaluate while the Ferrari should not.
Sprint planning meetings typically go into deeper detail than is appropriate for product backlog item estimating (whether in story points or ideal days). Since we become accustomed during sprint planning to breaking user stories into tasks and considering those tasks in more detail, there is a chance this will carry over into any story point estimating done during the same meeting.
So, when should story point estimating happen? I’ll describe the ideal case, which you can easily adjust for the real-world intrusions on your project. Projects typically start in either of two ways:
- A reasonably fully stocked product backlog is written before the first sprint begins and all items are estimated before the first sprint planning meeting. [If you do this, be careful not to write all user stories with too much detail. Each product backlog item you write represents an investment. User stories should therefore be elaborated just-in-time and in just-enough detail that they can be turned into functionality in one sprint.]
- We know we’ve got to do the project so we dive in. During the first sprint or two, all the user stories are written and estimated just like above.
On an ongoing basis, once per sprint I recommend that the ScrumMaster tell the team something like, “Hey, we’ve had five new user stories come in this sprint and we need to estimate them. Everyone plan on hanging around for a bit after tomorrow’s daily scrum meeting and we’ll play Planning Poker to estimate the new items.” Doing it right after the daily scrum helps cut down on the number of interruptions in total. I usually aim for having that meeting about two days before the end of the sprint. That way the product owner will have estimates on them so she can prioritize prior to the start of the sprint.
One question on that, Mike. I certainly agree with what you’re saying, but what would you do in the situation where, for whatever reason, the backlog items WEREN’T Story Pointed prior to the planning session? We run into that frequently in our workplace, and if we don’t ask the teams to provide Story Points before doing the task breakdowns, we find that we can’t really get any sense of the true velocity from that Iteration. For example, it wasn’t uncommon in our early Agile days to have a team complete some number of Story Points along with some amount of un-sized work, begging the question: what’s that team’s velocity?
Hi Matt–
In that case I would absolutely do the story point estimating right at the start of the meeting. If you don’t then you won’t know a velocity for that sprint, which is worse. I was simply describing the target for when we should try to do the product backlog estimating. Ideally, do it a few days earlier right after a daily scrum meeting. Sometimes, though, a late-breaking product backlog item will arrive and the team will need to estimate it at the start of sprint planning. There’s nothing wrong with that occasionally.
Hi i am a fresher in requirement analysis .I have been posted to analysis
the manufacturing business domain industry.I would like to know
how to analyis the business process and get the fields from the manufacturing company.I would be greatfull if you could give me with an
example of any business to gather requirements
Vasanth–To learn how to analyze any business process and identify fields that may be used in an application involving that process, I recommend any good software requirements book. One good book is “Software Requirements” by Karl Wiegers.
Hi Mike, would you ever look to re-estimate any existing stories on the product backlog aside from breaking down epics and estimating new stories? I am still pretty new to scrum and I am wondering whether there would be any benefit to regularly checking out the existing estimates on the whole product backlog and re-evluating at regular intervals during the project. Alternatively, would there be more benefit using the sprint planning sessions to re-estimate existing stories that are to be done just for that sprint.
Dave–
It’s perfectly fine to periodically scan through the product backlog to see if resizing is necessary. I don’t obsess over it, though, and would rather have enough items on the product backlog that over- and under-estimates wash out. The real key to re-estimating is that you should only change the estimate if you think it’s relative size has changed. If a few stories look much harder in comparison to others on the backlog than they did when we first estimated them, by all means, re-estimate them.
Mike.. The team I work on is an R&D team within in a large Engineering organization. The rest of the organization follows a particular form of scrum/xp. During the contruction of a release the product owners, architects and other leads start to create and “swag” the backlog for the next release. In my team we don’t have releases.. Instead we get “projects” dumped on our doorstep periodically.. We have a backlog of sorts of potential projects but we never know until sr management prioritizes one for us to work on. So there is no investment in estimating the “backlog” until a project comes up to the top.. My team has been struggling with how to handle this. IE: Do we estimate the “backlog” anyways? Once we are going to work on a project; do we do Sprints around the planning of a project, or only follow sprints (Scrum/xp) after we’ve written user stories (also note my team has no Product Owner..) Anyways I think this sounds like a great idea for a blog post!
Most articles that I find are based on product release types of projects and schedules.. Its hard to find anyone blogging about Agile and R&D projects.. Anyways, looking forward to many more great articles..
Thanks,
Gary
Gary–
I do think that even in an environment such as yours there are advantages to maintaining a well estimated product backlog. One reason is that you say senior management prioritizes work but how can they prioritize without knowing the cost of items on the product backlog? The estimates are those costs. If you leave them to prioritize without estimates from you they will supply their own mental estimates. Those are likely to be lower than yours and likely therefore to set expectations about delivery that you’ll have a hard time meeting.
If you’re asking if you should be in sprint mode sometime (i.e., during a defined project) and outside of sprint mode otherwise then I would answer that you should always be sprinting. At the start of whatever timeframe you prefer (2-4 weeks typically) get together and plan what you can achieve. Sometimes that will be something related to what you are defining as a project. Other times the work you commit to may be more exploratory or maintenance-oriented.
–Mike
Mike, I am a newbie in scrum, I’ve read a bit of literature on scrum, but one thing I have not gotten an answer to: We have quite a bit domain architecture so using only planning poker to estimate is a bit too little I believe.
1) How do I know how much is enough?
2) Also, Ken Schwaber says that you could use ideal teams for estimating i.e.: 1 developer, 1 tester, 1/2 technical writer, 1/2 architect. With only planning poker estimates up front, if that is how we should go about it, you need to do a bit of analysis for each user story (=backlog item) during the sprint. How does the team avoid having the e.g. testers, developers and technical writers sit and wait for the analysis to finish e.g. for the first couple of story points? E.g. say you have 2 developers, 2 testers, 1 architect and 1 technical writer. The developers and the architect starts working on the highest priority user story and together drafts the architecture. The developers listen in and comments i.e. more brains to solve the problem. After the developers are busy the architect updates the domain models/architecture models and then he starts on the next backlog item, possibly with a review by the team as he has a draft ready, i.e. more brains to solve the problem, great, but what does the technical writer and testers do? Draft the test spec and the documentation while listening in? I.e. I remember that was how we did it in our university teamwork, is that viable? At that time I think it worked ok. What I am looking for is how you accomplish exploiting all ressources.
Thank you and see you in Oslo in december.
/Thomas
Hi Thomas–
As for knowing how much architecture is enough, I think there are a variety of opinions that are all just about the same. Alistair Cockburn says do what is “barely sufficient.” Jim Highsmith says to do a little less than enough. I think that’s the same answer because I suspect that when someone does what they *think* is a little less than enough, it is the barely sufficient amount. My answer is that architecture should be done “just in time and just enough” to move forward through the next sprint / iteration. I think the same is true of things like user experience design–it should be done just in time and in just-enough detail as well. I’ve written an article on that.
As for ideal teams: I don’t think Ken advocates this approach any more. I believe that the last time I saw his materials he was advocating either story points or ideal time (“ideal individual days” but no one would ever call them that, rather than ideal team days). Because some user stories don’t involve all of the skills on an “ideal team” most teams that have tried that approach find it too hard. I used to know a few teams doing “ideal team days” but offhand I can’t think of any today.
Most teams struggle in their early iterations with the “miniature waterfall”, which is the next problem you describe in which testers have little to do during the first few days but architects are then the ones not busy at the end of an iteration. After a few iterations most teams figure out their own ways out of this trap. I’ve got a couple of sections on this in my upcoming book and since it’s a whole new topic I’ll try to make a blog posting soon about what to do.
Mike,
My organization is going through a lengthy process of getting our business units to buy into moving our “BAU” project from a very lengthy waterfall approach to a scrum approach. This is with a legacy application that has over 1200 open change requests (and new ones coming in daily). These change requests have very mediocre at best requirements statements. As part of our transition to Scrum we are attempting to move to user stories. Three general questions surrounding this transition that keep coming up are:
1) Do we go through and create user stories for all of the 1200 “backlog” items? (Or do we just create them for the highest priority items).
2) If we don’t create user stories how can the product owner determine the highest priority items
3) Should we go through and estimate all of the backlog items? (or again just the highest priority items?
In relation to those questions the statement is often made by the product owner “How can we determine the highest priority items if we don’t know the general duration of work? Cost is always part of an ROI calculation and our priorities often are fairly tied to ROI.
Thanks.
-Jeremy
I am not Mike, but was observing many similar issues in the teams and have some “general answers” for your “general questions” (though they might not be applicable to your concrete context).
1) If you’ve got 1200 requirements, most of the time it means over-specifying things. Does it happen often that thousands of requirements really stay unchanged until the end of the project? In my experience it happens next to never (with the notable exception of implementing a huge telecom standards). Could the last 400-1000 requirements be replaced with 4-10 big fat stories specified in a bigger detail later?
2) It might be really difficult to prioritize this small mandatory story over that small mandatory story. It is usually much easier to prioritize theme pack of stories over that pack of stories (Mike calls them “themes” in his book)
IMHO Mike’s “Agile Estimating and Planning” is an excellent guide for this kind of situations.
3) Scrum (as well as most of other Agile methods) is the art of possible. It is definitely a good idea to estimate the whole project at least roughly if it is possible. If it not possible though, well, your management has to make decision of whether it is able to live with the significant amount of uncertainty or allow the team spend some time on research-like spikes needed to figure out the story sizes. From my experience it usually pays off to estimate quite well the closest release stories (about 2-5 months) and very roughly estimate everything further.
Hi Jeremy–
I’m going 100% with Artem’s answer. (Thanks, Artem!)
My blog sent me an email with your questions shortly before I boarded a flight from London to San Francisco. I, of course, didn’t have time to answer before departing but I thought about my answer en route and it was exactly what Artem is advising.
I generally recommend that a product backlog never have more than 150 items visible to any one person at a time. That doesn’t mean we need tiny projects; it just means that sometimes items need to be grouped. Artem introduces “Themes” above. The other way is to write large user stories, which we call “epics.” By using themes and epics we can keep the volume of the backlog down to something reasonable. I’ve got a great (I think!) chapter coming on this topic in my next book, Succeeding With Agile. I’ll have draft chapters available on the website soon (possibly later today). The product backlog chapter will be up in a few weeks.
The only thing I’ll add to Artem’s point is to more directly address your product owner’s view that “How can we determine the highest priority items if we don’t know the general duration of work?” Your PO is absolutely right. The example I use is: Suppose you have never owned or even considered owning a car. You decide to buy one. If you don’t know their costs and just watch them drive by one afternoon, you might decide that fancy-looking red one with the Italian horse logo on the back looks nice. So you head to the Ferrari dealer and find, like I did, that a Honda is a much more affordable choice… So, yes, to prioritize we need to know the cost of things.
Thanks Mike and Artem for your quick responses. The 1200 backlog items are actually specific bug fix requests or small enhancements in all different areas of a 10 year plus legacy product. (some of the requests go back at least 5 years since being entered into our change management system.) There is a chance that some of them could be grouped together, but in all actuality they are independent efforts.
We are asked to estimate them independently. So while I agree with the idea that we need to know the cost before we can determine the highest priority, it could take a significant investment to estimate all 1200 items. (plus with new items coming in on a regular basis from our user community). Would you suggestion be to get the PO to come up with the top “150″ without estimates and then estimate only those? (And then keep ensuring that a top 150 exists. As we complete some work others are moved onto that list?)
Hi Jeremy–
I probably wasn’t very clear earlier. I don’t suggest grouping items because they are highly similar or in the same file. I suggest grouping them in logical areas to facilitate estimating. It would take forever to estimate 1200 items. There have to be some functional groups you can make from them. Suppose the product is Microsoft Word. We might group all the fixes in stylesheets, all the fixes in table support, all the fixes in pagination, all the fixes in display, etc. Then the team reads all the items in one group and puts an estimate on the collection. I would compare this to looking at the items in your shopping cart and estimating the total cost of the cart vs. estimating the cost of each item.
If that’s not possible for some reason then telling the product owner to give you 150 based purely on desirability of the feature (as you describe above) would be a perfectly fine approach.
When would you resize a backlog item? We’re mid-sprint right now, and realize that a backlog item was oversized. We have prioritized items in the backlog that we can take on to fill up the sprint; but we’re a new scrum team and want to be sure that we’re capturing velocity as close to ‘real’ as possible. Should we resize it during the sprint, or wait until the retrospective and handle it more as a ‘lessons-learned’?
Hi Kelly–
In general, I try to avoid re-estimating a product backlog item at all. I would only do so if you are convinced you were wrong about its *relative* size. The chief problem with re-estimating is that your backlog of finished items then contains a mix of items estimated before you did the work and ones after you did the work. That causes you to almost certainly misstate velocity compared to the product backlog of upcoming work with is (of course) all estimated before having done the work. The topic re-estimating is fully covered in the Agile Estimating and Planning book.
What is the best way to handle the following situation:
We have a team that want to setup a change management process, we have multiple systems which themselves contain multiple products, A team (not the dev team) has started to record change requests and are asking us for estimates of “how long” it will take to do a particular CR so that ROI can be done on the CR to allow prioritisation to take place!
We the developers really want to view CR the same as any other item on our backlog and simply estimate it relatively in terms of Story points to allow prioritization to be done by a PO. I can appreciate that they think they need a duration to help them justify the change request, I feel it is ok to give an estimate in hours for ROI purposes but not for planning! any thoughts appreciated
Hi Kevin–
I don’t see why this other group can’t work with your estimate in story points. In fact, it should be easier for them to calculate ROI. All they need to do is calculate how much a story point costs on average. To do that, look at how many points your team or department did last year or last quarter. Divide that into the amount of many the team or department was paid during that period and you’ll get a dollar (or Euro, etc) amount per point. I did this recently with a team and got $3000/point. If the other group is assessing a 3 point story, they can estimate it as costing $9000.
This will be a $9000 based on actual data. If you had told them “12 hours” they would have multiplied 12 hours times some cost-per-hour but that would have been a bad estimate because we don’t know how accurate the 12 is. Using story points here should be easier and should help them get a better ROI estimate.
Hi Mike, I have another kind of issue. In our group, we estimate stories when they come on the backlog. Then, after this initial estimate, many of the stories (epics, small ones, etc.) are taken by the Product Owner/UX team and designed. After this design we typically have to 1) reestimate again, and 2) break the story down based on the design that was given to us. This seems a bit backwards or out of step from how I think it should happen. Wouldn’t the PO team work on breaking the stories down into manageable pieces before doing the UX design, etc.? There just is not a lot of information on how a UX/visual design team can effectively interact in the scrum process. Any suggestions or insight?
Hi John–
Yep, sounds backwards to me. I would, however, continue to estimate that initial story only to the extent the PO needs that estimate to prioritize the feature. Say I want I new custom report design feature in a product. If that costs 400 story points, I don’t want it. If it costs 50, I want it now. If it’s 200, I want it but I’ll wait a bit as we have higher value stuff to do first.
My new book, Succeeding with Agile, will cover the role of user experience designers / interaction designers on Scrum/agile projects. You can pre-order Succeeding with Agile now on Amazon or access it immediately on Safari.