This question came in and I was asked to see about answering it:

We are struggling with how to forecast feature delivery to stakeholders / customers in Agile – esp for a client data migration project where we seem to keep finding bugs and exceptions. How is forecasting handled in Agile?

I spend a lot time answering this question, primarily because our software ScrumWorks assists in doing this in a variety of ways, and it’s my job to sell ScrumWorks. The underlying concepts and methods are not software dependent however, just easier. So I am going to run through some of the basics here in Agile forecasting.

What you will Need:

• Stable, Cross Functional Scrum teams.

A team needs to stable to be measurable. If our team is constantly changing members they will not only fail progress into norming (much less performing) but they will never be able to provide a consistent Velocity. Keep in mind that Velocity is simply a measurement, the average rate that your team completes work measured in whatever relative estimation scale you are using. If you were trying to measure the average number of miles you get on a gallon of gas you wouldn’t have a very useful value if you changed your car every 4 miles. The same applies to a team, the more stable they can be the more reliable your Velocity will be.

• Consistent Relative Estimation of your Backlog Items.

Backlog items need to be estimated in a relative fashion, as in; “Item A is a 2, and Item B is twice as hard, therefore it is a 4″. Over time this type of estimation, with a stable team, allows for more consistent estimation. Forecasting in Scrum isn’t about accurate estimation, just consistent estimation. Estimates are guesses, and probably wrong. If we are consistently wrong we can still use that data to forecast.

• A Product Backlog that isn’t just User Stories.

A misconception I run into constantly these days is that the Product Backlog is just user stories. This couldn’t be more wrong. The product backlog is a prioritized list of Everything the team needs to do to complete the project. Defects need to be prioritized into this list, development spikes, technical debt, functional requirements. If the team is going to do work on it and it is related to this project then you should be putting it on the backlog, estimating it, and committing to it, just like your User Stories. Without a relatively clear idea of all the work you will have to do forecasting becomes a lot less certain.

How you go about Forecasting:

Once you are set with a stable velocity and a backlog populated with all the work we need to do you will want to try to get as much of it estimated as possible. These estimates do not need to be solid until the team is ready to commit to them, high level estimates are good enough as you go down in the backlog. I usually suggest time boxing the estimation of items, ~5 minutes per item with a team that has a good handle on what an estimate means to them can be good enough for decent forecasting. A sold ScrumMaster can really help when it comes to this type of work. It is very likely that the items will be re-estimated when they are closer to being committed to in a Sprint.

The most basic form of forecasting just requires some simple math. For example: our team has a velocity of 50. A sprint is 2 weeks. This means that a 2 month release is about 200 points. If you have more then 200 points within the release it’s unlikely that you will finish. Less then 200 you are looking good. This doesn’t really help us visualize, or forecast dates, but it can tell us quickly if we are going to meet a target date.

When we want to actually forecast we need to plot 3 things: The points a team completes in a sprint, the total points on the backlog, the rate at which our scope changes. The third one is the hardest, it requires us to record each change made to a backlog item’s estimate, but it is a very important piece of this.

Visually we can create a chart that looks like this:

The actual ScrumWorks 2.0 release back in ’06

On this report the Blue Line jumps up every time the Team completed a backlog item and the Product Owner accepted it as complete. The trend line is the team’s Velocity.

The Red Line rises or falls any time backlog items are added, removed, or re-estimated. The big drop between July 15th and 30th was when the Product Owner removed work from the backlog, and then on August 29th appears to have put it back in, or added different work. The red trend line represents the scope change. In this case the scope was trending upward.

Where the red and blue trends converge you have a potential release date. You could also use such a report to note that the velocity trend will converge with the baseline (which in this report’s case is 450) between February 10th and the 25th and say that would be the date all the work should be finished assuming no more work is added (which is pretty safe to say based on the recent trend).

This particular report is very simple and can be improved with a broad variety of options.  There are some traps people fall into when they are practicing agile that will make this report less valuable however:

• Changing estimates after they are scheduled in a sprint is something you do not want to do. Keep in mind that we are comparing the rate at which we complete points to the points that we have not completed yet. If we change our estimates after the fact we are suddenly comparing reality to estimates, and defeating the purpose. We want to compare the rate that we consistently complete flawed estimates to the total flawed estimates we haven’t started yet. If we are consistently wrong we can still generate a solid forecast because we are comparing apples to apples.

• Partial Credit is just waste. Don’t bother doing it. Velocity is the average, if one sprint results in 10 points completed and 40 partially completed, and the next sprint we complete 90 points, the average is still 50. If you look at the report above you can see an example of where this occurred, right at the November 27th mark. You have one really bad looking sprint, followed by one really good looking sprint. That’s reality, the report will reflect it correctly. Any consumer of such a report needs to understand that it is the average that matters, not what happened in any specific sprint.

• Estimation is a ritual the team uses to surface questions about a Backlog Item that need to be answered before the team can commit to completing that item within a sprint. Estimation is not a way to get estimates, estimates are simply a happy and valuable by-product of Estimation. Good Agile reporting is a passive thing that stays out of the team’s way, even as it answers important questions.

• Time Estimates technically work with this report, but not for the process of Estimation. Remember that Relative Estimation is a requirement for this type of forecasting to be successful, it’s not just a suggestion. If you are estimating your story points in time you are going to have trouble.

This blog entry is really just a taste of Forecasting in Agile. I’ve personally seen it work, surprisingly well in fact, and this is typically why this method is what I immediately go to when someone asks me about Forecasting, but it isn’t the only way to do it.

The post Forecasting in Agile appeared first on blogs.collab.net.

Curious, anxious, or just plain frustrated with Agile? Be calm- our Agile Guru’s are here to help!

In these complimentary 1-hour sessions, our Scrum trainers will cover the most daunting issues that Agile practitioners like yourself are experiencing, suggest solutions, provide best practices for adoption, and provide you with knowledge to accelerate your organization’s path to success.

CollabNet’s Agile Gurus are some of the most versed Scrum trainers around and each trainer has an abundance of first-hand examples that they would love to share with their peers. Each trainer’s perspective can be used to apply to a variety of different situations, so don’t feel limited to attending only one Guru. Register for all if you like!

Here are the upcoming Agile Guru Sessions:

May 31, 2013 at 10am-11am PST with Luke Walter, CSP 

June 28, 2013 at 10am-11am with Jimi Fosdick, CST

July 26, 2013 at 10am-11am with Adam Weisbart, CST

Enjoyed one of our Guru’s and want a copy? Don’t worry. All live sessions are recorded and you will get a personal copy to share with your colleagues after registering.

In addition to these complimentary Guru sessions, CollabNet offers a wide array of public and private training courses all over the globe. Designed to address issues with organizations of all sizes and anatomies, Agile training at CollabNet will:

• Identify problems and opportunities in your organization
• Learn all the rules, artifacts, meetings and processes for Scrum
• Become a Certified Scrum Master or Product Owner upon completion

CollabNet offers free Agile Guru sessions once a month so stay tuned for an updated list of sessions. We hope to see you at the next Guru!

The post New Agile Guru Q&A Sessions! appeared first on blogs.collab.net.

We had a really great time on BED – Berlin Expert Days last Thursday and Friday. The conference was very well attended – we heard about 700 participants – and the talks gave invaluable insights into what’s hot in Java, DevOps, NoSQL and everything related to it. Among many other things we learnt how SoundCloud scales (technically as well as organizationally, Ruby has already crossed its peak as new stuff is written in Scala), why Adam Bien typically removes 60 percent of production code on his gigs and how ImmobilienScout24 managed to establish a DevOps culture by encouraging every single individual to change the organization from the bottom guerilla style. We will definitely apply the best practices we heard about in our own organization (we like to get my hands dirty with Vagrant next).

We contributed two talks to BED as well, one on how to make Code Review enjoyable again by Marrying Gerrit with Jenkins and one on how you can save multiple hours a week by using your Eclipse IDE efficiently. Both talks were very well attended and we got some interesting questions and great feedback.

The question most often asked was where one could get our slides so here is the answer:

Slides for Git/Gerrit/Jenkins talk

Slides for Eclipse Productivity talk

As our Git/Gerrit/Jenkins talk included a live demo which is not part of the slides, we also encourage you to watch this recorded webinar in case you like to see how you never have to look at code reviews again before Jenkins has already guaranteed a certain minimum quality (compiles, test run through, coding styles met, IP not violated, etc). Furthermore, we have written a separate blog post on how to configure the Gerrit Trigger plugin in the past.

Another question that came up was where we got our industry statistics on the popularity of code review practices, defect removal efficiency and costs of code review compared to other methods like pure Scrum, desk checks and static analysis. The answer is in our slides but for those of you who like to know immediately, check out this review for the great book we quoted for those numbers.

Last but not least, we would like to thank CollabNet Marketing for having sponsored BED, we can tell that our prizes for the raffle were definitely appreciated by the lucky winners.

Looking forward to BED 2014 now.

Dharmesh, Dariusz and Johannes

The post BED Time Stories – Sharing Gerrit, Jenkins and Eclipse Knowledge appeared first on blogs.collab.net.

Emerging IT applications are transforming the way business is done today. Application life-cycle Management (ALM) tools are the need of the hour. The integration of ALM is essential to remove major inefficiencies and bottlenecks in the software development process. If integrated properly, ALM can help an IT company develop best practice for virtually every major phase of the software application process, including:

• Research
• Requirements planning
• Prototyping, engineering, and design
• Cost and time to market (resource consumption, etc.)
• Programming
• Testing
• Risk management
• Issue and defect tracking
• Metrics definition and measurement

The use of ALM helps a company assess, improve, and maximize, collaboration between team members. It helps them refine core development processes across teams involved in the designing and delivery of software applications. The result is greater productivity, cost efficiency and the highest possible results.
To ensure the best results, ALM needs to be efficiently integrated with other tools within the organization. The following are a few key results that can be achieved with the proper sync of an ALM tool:

• Teams reduce rework
• Improve development processes
• Attain higher-quality of products
• Achieve timely completion of project
• Ensure end-to-end monitoring between work items
• Reduce cost

What exactly can one expect from Application Life-Cycle Management?

• Increases productivity
• Allows teams in the organization to share best practices for development and deployment
• Allows developers to concentrate on business requirements
• Maintain and stabilize quality
• Ensures that the needs and the expectations that were created for all end-users are met
• Speeds up the whole work process
• Cuts down the time to develop the software and bring it to the market
• Brings the best out of organization’s investment in labor and technology capabilities
• Ensures quality output in the development process

With the development of technology and the demand of high quality software, companies are looking for a better process that can help them execute projects with a concrete plan. It can also help to bridge the gap between team members, provide full traceability between project artifacts and eliminate the need for unnecessary documentation hassles. With proper implementation of Application Life-cycle Management tools, IT companies can comply with all their internal and external requirements. Also with proper execution, integrated team work, an attentive business management team, and integrated Application Life-cycle Management, it is possible to build a user-friendly application better, faster and on budget.

To learn more about how your organization can benefit from the implementation of ALM, visit http://www.collab.net/products/teamforge

The post Application Life-Cycle Management Is Much More Than Just Writing Code appeared first on blogs.collab.net.

As working adults, most of us have limited opportunity to assimilate new skills and information. This is especially true for information that presents a disruption to established patterns that ease our already taxing cognitive load. So, while misbegotten, the search for ‘best practices’ for agile development is understandably popular. With plenty to do, and precious little time, most prefer the elevator pitch, the executive brief, the Cliff’s Notes version. Seeking agile best practices is essentially asking for a pre-sort: “help me fit this into a frame I already have so I can use it immediately with a minimum of effort”.

Unfortunately, this frame doesn’t fit the agile picture. A best practices mindset assumes that every problem is more or less the same; all that’s necessary to approximate success is the rote application of nostrums gleaned from the experience of your predecessors. This approach makes sense for some types of work – baking, for example – but unfortunately not for the type of work we encounter often in modern software, and certainly not for the challenges presented by complex product development.

But, you might argue, isn’t Scrum simply a collection of best practices for agile development? Apply the cookbook rule: When followed to the letter, does Scrum guarantee a viable, high-quality product? There are reasons why Scrum is the dominant agile framework, and why I enthusiastically teach and coach teams to use it, but the answer is no – it guarantees nothing. Scrum is best likened to a game, one played by development organizations in order to improve their processes and hopefully by extension, their product. But this improvement is far from guaranteed. Like football (“soccer” in the United States), it has rules and roles and artifacts that must be observed, but simple observation ensures nothing except that you’ve played a game of football. If your players are in poor shape, lack energy and imagination, and are uninterested in enjoying the game or improving their performance, this will surely show in an uninspired, boring match that isn’t likely to yield either good sport or entertainment. Likewise for Scrum; Among other things, it takes commitment, focus, openness, respect, and courage (these are, by the way, the official five values of Scrum) to ‘play’ Scrum well and to thereby realize its benefits.

So then, what are the agile best practices?

The first answer is: There are no best practices for agile development – at least not as best practices are commonly conceived – because the problems for which agile is intended aren’t solvable by prescriptions. The closest we have are the principles behind the Agile Manifesto. But if you’re looking for sure-fire how-tos, you won’t find any there.

Another (somewhat flippant) answer is: They’re all best – do them all. Probably can’t be any worse than what you’re doing now.

Another answer, one I think most in keeping with the empiricism embodied by agile values and principles, is: It depends – on you, your team, your product, and your organization. I recommend you try as many as you can, and find out for yourself.

The post Getting Beyond Agile Best Practices appeared first on blogs.collab.net.