In a recent webinar on using the SLIM tools and methods in an agile environment, we showed a template for agile projects included with SLIM-Estimate. I was asked, "Since agile teams are a fixed size group that stays together throughout the work on the release, why doesn’t the agile template use the Level Load shape?" My answer was the typical short answer to a complex question, "It’s complicated and it depends." In this blog, let’s take a look at some of those complications and dependencies.

The team, the whole team, or nothing but the team?

When using SLIM-Estimate to estimate the effort required for a release, agile or not, you have to decide, "Whose effort are we interested in?" When describing a team in a scrum project, we usually talk about three major roles: product owner, scrum master, and team member. These people are, in general, full time on the project. If you are only interested in estimating the effort of these full time team members, then you may want to use the “Level Load” shape in SLIM-Estimate. The total effort of these people is based on the number of people multiplied by the duration of the work on the release.

When it comes to agile, there are common myths and misconceptions about project estimation and tracking. In Part 2 of this PDU-approved two-part webinar series (which can be viewed independently or together), presented by QSM's Andy Berner offers corrections to these, such as:

• Why velocity is not a good predictor of release duration
• Why burndown charts will not be close to straight lines
• Why change and churn are not the same thing
• Why looking at just the values of metrics alone is not enough

While some longstanding principles about software estimation still apply, agile methods require some significant changes to how we estimate. This webinar shows you how to leverage the SLIM estimation and tracking tools to properly interpret metrics collected by agile teams and ensure that agile projects meet their goals. Andy Berner demonstrates how SLIM fits with the principles of agile development, and discusses milestones, productivity, project control, data collection, and looks with an eye towards further research.

Watch the replay!

QSM is pleased to introduce our Estimating and Tracking Agile Projects workshop, the latest in our popular workshop series.  We introduced a number of workshop offerings last year in response to a growing demand for basic educational courses on software estimation and project management from our clients and prospects. 

The purpose of our Estimation and Tracking Agile Projects workshop is to give students a clear understanding of how to estimate and track agile projects at the project release and portfolio level which, in turn, helps establish more reasonable expectations for developer sprint/iteration level planning. Participants will learn how to "embrace change" in the estimation and tracking process while also effectively managing stakeholder expectations based on scope. The workshop content includes the most effective methods for sizing agile projects and uses SLIM as an example to show how a scope based parametric tool can be used to estimate and track effort/cost, duration and quality in an agile environment.

After completing the workshop, attendees will have the ability to estimate and track agile projects at various stages in the software development life cycle. They will also be able to explain, from a software estimation perspective, what makes software projects using agile methods truly unique vs. differences in terminology.

QSM offers a number of additional agile resources for our clients and prospects, including articles, blog posts, and our upcoming Agile Estimation: Beyond the Myths, Part 2 webinar.

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?

In agile development, getting the backlog ready and grooming it take serious consideration and work. You need to plan, budget for, and track this work. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Andy Berner talks about his upcoming presentation for Agile Development Conference East, the importance of keeping a well-groomed backlog, the pitfalls of the impossible zone, and why it's vital that you and your team keep your tools serving you and not the other way around.

Read the full interview transcript here!

This case study for Agile Connection by QSM's Taylor Putnam serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.

Read the full article!