Our recent webinar, Agile Estimation: Beyond the Myths, Part 1, presented by Andy Berner, featured a lively Q&A session. Here are a few of the highlights that you can catch in the PDU-approved replay.
Q: You talked about different types of work and how they're done concurrently. What about the work of developing the system architecture?
A: How architecture is determined in agile projects is a really interesting question. Grady Booch, who is one of the great proponents of software architecture used to say that the biggest difference of opinion between him and Kent Beck, who is thought of as the inventor of agile, was the extent to which architecture is planned versus evolved. So there's controversy, but I think all agile methodologists would agree that some basic architecture constraints are an input to the coding work, and thus we would consider that as part of "getting to ready," and also agree that some detailed architecture decisions evolve along with the detailed design as part of “getting to done.” So it's split. The more complex the project, the more likely you’ll need strong architectural input that was part of "getting to ready" and should plan more architectural effort as part of the "getting to ready" portion.
Q: Can you create an agile estimate using function points as an input?
A: Sure. As I mentioned, the SLIM Suite is very flexible about the method of sizing that you use. So you can choose a sizing unit, set the appropriate gearing factor, and SLIM-Estimate will generate the same estimate as it would if you were using story points, just sized differently. So if I go to the Solution Assumptions in SLIM-Estimate, I can change the sizing unit there. So yes, you can use function points to measure an agile project based on the scope, but you have to do the function point count based on the entire scope. You have to look at the user story map and the shape that it's in. Look at the top levels and understand from the top down what the entire scope is so that you can do the function point counting and find the logical data stores and the logical processes and so on.
Q: Any recommendations on approaches to determine the gearing factor of story points?
A: What a good question! And we've been doing some research on that and we've been finding that it's different in different organizations. The best way is to callibrate your own history. We talked about that company level of normalization and one of the first things you need to do to get that is to agree on a scale by which you're measuring stories. Some people measure story points on a scale from 1 to 10. Other people might have used powers of 2. Those will give you very different counts of story points. So the first thing is to settle on a standard way of counting. What's become most common is a scale that Mike Cohn introduced in his book on agile estimation where you use what's called Fibonacci series - 1,2,3,5,8 - so that when it's going up it's not going up by twice as much. First settle on the scale and then you need to practice to get inter-rater reliability. We've been doing this within our own development at QSM where we have different developers rate the stories and then we discuss whether we had different sizes. In the SLIM-Estimate agile template, we have a Size Calculator that you could use to measure things in terms of small, average, and large. We have some recommended gearing factors that are based on the QSM database and also based on some individual research that we've done, but what we've found is that you can start with our recommended gearing factors but you'll need to do your own normalization and see how people within your company rate it, so keeping the history is really important for that.
Q: Should I enter the total story points of the release in my estimate?
A: Yes, that's what we're looking for. When you're trying to size a release, if you've measured the backlog in story points (and be careful that you don't count a parent and child stories together), then you'll be able to add up the story points and that would be what you could enter for the size input of the estimate. So if you had a set of stories, you could count up the total story points and just enter that into SLIM-Estimate's Solution Assumptions. Another way is to use SLIM-Estimate's Size Calculator to calculate that, which will do that for you.
Q: If you don't have all the epic-sized stories broken down into the smaller iteration-sized stories, can you estimate a release based on a backlog of epics?
A: Sure. You would need to have them sized appropriately large and not all epics will be the same size, so you can still give the epics a number of story points, but it would be a fairly large number. It might be 60 or 100 or, depending on the epic, it might even be 200 story points. So if you have a large epic, you can get a size. The less detail you have, the more risk there is in the estimate, which is the same for any kind of project with any kind of software sizing. If all you know is very high level epics, you can still use that to get what we call a "T-shirt size." That will tell you if you have a very large release or a medium release. So yes, you can use epics as the sizing measure. It's similar to using features as a sizing measure and SLIM users have been doing that for years.
Q: We're using the Scaled Agile Framework. Where does SLIM fit in with that?
A: SLIM fits in a few places in SAFe. As I mentioned, SAFe version 3 does introduce the first class notion of release and that's the level in SAFe that corresponds to the project estimation we've been talking about in this whole webinar. At that middle level in SAFe, you can look at estimating the release. At the portfolio level, the SLIM Suite and methods can help you plan the number of teams. Keep in mind that at the portfolio level, you have very long-lasting epics that you're aiming for and you're going to divide those up into what SAFe calls "agile release teams," but agile release teams don't have to all be the same size. Each agile release team is made up of several small agile teams, but you may have five agile teams on one agile release team and 10 agile teams on another. How do you know how to allocate those teams? Well the SLIM Suite can give you the kind of duration of effort estimation that you need to help you do that allocation. So it's useful at the portfolio level and it's very helpful for estimating releases that are now a first class element of SAFe version 3.