Skip to content

How We Actually do it: Accounting for Bugs in an Agile World

February 27, 2009 by Jack Milunsky


Today I'd like to share with you a really important aspect of Agile software development - how to account for bugs in your daily plans.

I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again:

"Should I track hours burned fixing bugs?"
"Should the hours burned on fixing bugs count toward my Story Point velocity?"
"When do you schedule bugs and should this be done during Sprint planning?"

You Need to Account For Bugs

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we're considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don't, you will have an inaccurate measure of your teams productivity - something that will definitely lead to poor planning and late deliveries. (....read more)

Time to fix bugs therefore, should come out of your teams available capacity. So when one schedules bugs to be fixed, bugs should be estimated just like you do with tasks on the sprint backlog. Developers must therefore determine for each bug scheduled, the hours remaining to complete the bug daily. And this WILL be reflected in the daily burn-down along with tasks.

Calculating the Teams Capacity

Essentially teams have a certain capacity i.e. available time during the week to do meaningful work. This can be calculated as follows:

(# of team members) * (# days in the week) * (hours in the day) = capacity

You should however modify the capacity to reflect reality (time spent in meetings, doing email, vacation etc) so this can get quite complicated. The best thing to do is to figure out what percentage of time per day you get real work out of the team on AVERAGE.

At our company we work on a 4 or 5 hour day therefore:

Actual Capacity = Capacity * 0.5

Once again, don't get hung up on being extremely accurate as this all averages out in the end. Just be reasonable in your approach. If you want to take vacation into account etc one can get quite fancy about this, but usually a rough estimate works fine. It does for my team.

Resolving Bugs Shouldn't Count Toward Your Story Point Velocity

The time spent resolving bugs however should NOT be counted towards the Teams overall Story point velocity. i.e. I'm not going to give my team credit for buddy code!

Bugs should be scheduled into a sprint or iteration along with user stories during the Sprint planning meeting. So the total time to implement tasks and fix bugs should not be more than the available capacity you determined for the Team (See above capacity calculation). Note that this total time in hours is the intersection with the Y-axis on your burndown.

I know many coaches will argue that bugs should be tracked seperately and that bugs should be dealt with in the sprint that they're found. However in practice this is not always practical. Try it, and you'll improve your teams predictability significantly.

Next week I will give a detailed account of how we do Planning.

If you have any questions about Planning or Bug Tracking in general or if you have strong opinions on this topic, please don't hesitate to pitch in!

About the Author: As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at http://twitter.com/agilebuddy

Comments

Counting towards velocity

February 27, 2009 by Mike Evans (not verified), 5 years 25 weeks ago
Comment id: 2292

If you do not count bug fix work toward your overall velocity, how do you accurately choose a work-load at the beginning of a sprint? This would be most problematic for team just starting out. I'm not sure I understand the necessity of the capacity calculation. If you account for all work done in your Velocity calculation you could use that figure (adjusted for vacations, etc..) to judge how much work can be done. If you are not using Velocity to judge sprint workload and translate all work into hours before judging how much work can get done in a spring, what are your points used for? A pat on the back for how much non-bug work we got done in the sprint?

Assume that the team is consistently committing to 20 story points and 5 points worth of defects. In iteration 5 they have no defects to work on (yay!), if defect points don't contribute toward velocity, they are going to commit to 20 points of story work. They will be done early and it won't be immediately apparently what happened. If the team responds at the next sprint planning meeting and selects more work, but this time has a defect to work on, they are going to fall short of their commitment.

I'm just trying to understand.
Cheers!
-Mike

Bug fixes don't count on the release burn down chart

February 27, 2009 by Dennis Stevens (not verified), 5 years 25 weeks ago
Comment id: 2293

Mike,

You are right, bugs fixes do get counted in the team's sprint capacity. You set aside a certain amount of capacity (story points per sprint) to fix defects from old code. You estimate bug fixes in story points, and include them in the sprint. You fix the bugs and track them on the sprint burn-down. This determines the teams sprint capacity.

The distinction is that you aren't making progress if you are fixing bugs. Time spent on bug fixes is time spent not moving new features into production. A Product Owner can't determine the progress we are making towards a product release and therefore make accurate decisions without understanding the rate we can move working (bug-free) code into production. So bugs fix time doesn't count as project velocity and its not additional work on the release burn down. You get better velocity by producing less buggy code.

In the case where you get done early, you should have some extra backlog groomed and fit that into the sprint. If you are producing more production code (not fixing stuff that is broken) you get credit for it and your velocity will exceed plan. Do this often enough and you can increase velocity for planning purposes. So you know how much capacity you have, and you set some aside some of it for defects. But you don't count your bug fix time towards team velocity for product planning purposes.

Accounting for bugs and story point velocity

February 27, 2009 by jackMilunsky, 5 years 25 weeks ago
Comment id: 2294

Awesome questions Mike. Let me try to explain ...

Story point velocity is should be used as a guide in determine how many "done" user stories you can accomplish in a given sprint. So for example, my team on Agilebuddy on average deliver 45 story points in a two week sprint. Some sprints we do more (we have gone as high as 70) and some sprints we do less. So when we do our Sprint planning i.e. selecting which and how many story points to put in a sprint we go by our Story point velocity. So in this example, we would schedule 45 story points worth of work. But, we're not done yet.

Now, we need to break those story points down into tasks and then estimate hours. Once you're done and you total the hours, you may have more or less hours than the capacity you have. Part of this process is adding up the hours it's going to take to fix the bugs as well. So the total time to complete the tasks in hours plus the total time to fix the bugs in hours should be less than or equal to the capacity you have available.

Now, if it isn't you can work with the product owner to drop a couple user stories, or drop a couple of bugs based on priority. Or your team can simply commit to having it done.

Hope this helps,
Jack

>>I know many coaches will

February 27, 2009 by Michael Dubakov (not verified), 5 years 25 weeks ago
Comment id: 2295

>>I know many coaches will argue that bugs should be tracked seperately and that bugs should be dealt with in the sprint that they're found. However in practice this is not always practical

I have just one question. Do you have Definition of Done for user stories? If you have it, how it happens that you do not have "Zero Bugs" rule in your DoD?

What Done means

February 27, 2009 by jackMilunsky, 5 years 25 weeks ago
Comment id: 2296

Thanks for the question. Again, this is a really good one.

Well firstly, everyone's definition of "Done" is different although there is general understanding that Done includes bug fixes. However, in practice you don't always find all the bugs during the sprint. Many times you find bugs after you have deployed to production and the customer starts using it. Additionally, some bugs you may decide to push out (they may be minor).

Secondly, during the sprint, when you find bugs they need to get added just like tasks do and you need to account for how long it's going to take to fix. This will cause the burndown total hours to increase on that day they're added.

Jack

>> Many times you find bugs

February 27, 2009 by Michael Dubakov (not verified), 5 years 25 weeks ago
Comment id: 2297

>> Many times you find bugs after you have deployed to production and the customer starts using it.

Of course it happens and even more often than desired ;)
There is HUGE difference between bug found during story development and bug found by customer. I did not get the distinction in the article. Bug found during story development is MUCH easier to fix, since you have focus on the story, you know what you've done 2-3 days ago and everything is fresh in mind. If bug found next month, it will take time to switch to it, include into the new build, deliver, etc.

>> Additionally, some bugs you may decide to push out (they may be minor).

To be honest, we've tried to push out minors bugs. As a results during 1 year we accumulated about 100 bugs (with Normal and Small severity) that live in the database in Open state. Can the application run without these bugs? Yes, it can. Is it good? No, it is not. This practice does not work for us and currently we have zero bugs rule in DoD. BTW, it'll take time to get rid of all these bugs accumulated during 2 years.

>>Secondly, during the sprint, when you find bugs they need to get added just like tasks do and you need to account for how long it's going to take to fix. This will cause the burndown total hours to increase. on that day that you find them.

No objections here if you track burn down in hours. But there is a simpler approach. Normally you have quite the same development/bug fixing ratio for each iteration. So you may just run 1-2 iterations and define the time you need to fix all discovered bugs.

Finding bugs and accounting for them

February 27, 2009 by jackMilunsky, 5 years 25 weeks ago
Comment id: 2298

We have a zero bug rule as well here at Agilebuddy. But unfortunately the realities are that not all companies can have such strict rules - although they REALLY SHOULD! It's so easy for these bugs to pile up. We also have a 100% test coverage rule by the way but in reality we're sitting at around 95%.

I personally am not fond of running specific bug fix sprints but this is an approach that many companies follow and more often than not, companies have to do it this way.

Thanks for the contribution
Jack

>>I personally am not fond of

February 27, 2009 by Michael Dubakov (not verified), 5 years 25 weeks ago
Comment id: 2299

>>I personally am not fond of running specific bug fix sprints but this is an approach that many companies follow and more often than not, companies have to do it this way.

C'mon! That's plain wrong practice! It is just a bug fixing phase in waterfall. It contradicts to agile development nature. How it sounds for example "well, waterfall is bad, but companies have to do it this way".

I think we should not try to advocate bad practices in any case, but just say that they are bad and should not be followed. No excuses.

Best,
Michael Dubakov
http://twitter.com/mdubakov

Bug sprints

February 27, 2009 by jackMilunsky, 5 years 25 weeks ago
Comment id: 2300

I completely agree with you that it's bad practice. I am not suggesting in any way that this is what companies should do. I was just saying that there are still many companies that work this way.

Jack

concept of commitment and slack?

February 28, 2009 by Derek Neighbors (not verified), 5 years 25 weeks ago
Comment id: 2301

I like that you are talking about this subject and I'm not sure there are any "correct" answers and more ideas to implement to find what works best for you. Here are some quick thoughts I had while reading the article.

Zero Defect Mentality
The current approach you are using has the assumption that defects will continue to be found at a pace to have a sufficient future impact. I think once you take the approach that defects should really be a rare occurrence and that defect free software development is possible it will change how you manage this problem. I like the comment that talks about "done is done" problems. If you are seeing a high rate of defects when things are going into production it is a symptom that your current process is broken in some way.

Defects Should Be Estimated
I guess when you get to the point where you feel its viable to be defect free then you come to the conclusion that original story points are in fact the measure of future defect estimation. That is you do not estimate defects because it means you didn't actually correctly complete stories that had estimates marked as completed originally. If you are forced to consume those defects it gives you a more realistic picture of what your velocity really is...

Before you completely freak on this concept.. if a team starts to write sloppy software in order to increase velocity.. ie: I increase my velocity from 12 to 20, but am writing really bad software... Then bugs come back three iterations later... I am able to continue my 20 point velocity without it raising concerns because I adjust for all the defects showing up. If instead I was forced to consume them. My velocity would drop significantly. The product owner would freak and we would have to discuss why we are seeing so many defects.

Consider Slack
One thing I have seen is teams add in a small amount of slack to their iteration. So while they might be able to do a 22 velocity they commit to say a 20 instead. This allows them to deal with defects, tackle code debt (refactor), do research or deal with issues that were not for seen.

I am not a huge fan of the slack method and I hate the estimate/include method. I guess I just believe in defect free enough to inflict pain that forces us to deal with it. I loved the post and that someone is talking about it.

Zero Defect Mentality

February 28, 2009 by Michael Dubakov (not verified), 5 years 25 weeks ago
Comment id: 2302

Zero Defect Mentality sounds good. But in reality you still have errors after production. EVEN in predictable and quite easily testable industries (hardware, cars, etc) we have problems with 100K power adapters or hard drive problems (seagate recently). How can we expect zero defects in software development? It is harder to test, harder to define in details, etc (it is complex adaptive system, we can't predict al effects). So bugs in production is a NORMAL thing, we can't bring them to zero. But we can (and should) minimize them using all possible ways. Anyway, we have to deal with bugs in production.

Zero defects mentality kill motivation? ;)

February 28, 2009 by Michael Dubakov (not verified), 5 years 25 weeks ago
Comment id: 2303

BTW, quote from Lean Software Development by Mary & Tom Poppendieck :)

"One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield"

Bug estimating

February 28, 2009 by jackMilunsky, 5 years 24 weeks ago
Comment id: 2311

Thanks for all the comments to this blog.

I do want to add a little more color to this thread.

When we're estimating user stories, we estimate in story points and that estimate is a relative estimate against already previously completed user stories and is our best estimate of effort to totally complete the user story taking into account size, complexity, risk, technology, unit tests required, documentation etc... i.e. everything we can think of to declare the story as done.

During the second half of the sprint planning meeting, when we breakdown the user story into tasks and estimate the hours for each task, that's where we take any left over bugs, or bugs that were found after the fact and assign hours to those bugs as well and that is added to the total of task hours and is reflected on the burndown.

Generally speaking, most teams when breaking down stories into tasks and estimate hours they don't include hours to fix bugs that haven't been found yet. Remember that the burndown is supposed to reflect reality in real-time.

Also, during the sprint, just like when you think of a new task and you add that to the sprint backlog, when you find a bug during the current sprint, you have to add that bug and estimate it's hours so that the time is accurately reflected on the burndown. To me, Bugs and Tasks are almost the same thing and should be treated the same.

Cheers
Jack

Re: Dealing with defects/bugs and capacity planning.

March 2, 2009 by Kane Mar (not verified), 5 years 24 weeks ago
Comment id: 2314

Hi Jack (et al),

Firstly, I'd like to say this is an interesting article that raises several interesting points. Some of these points are generally agreed upon in the wider scrum community and some are not. Rather than try and address all the relevant points here, I'd like to address just two of them below:

1. My personal recommendation for *customer* report bugs (ie. existing or legacy bugs that are in production) is that they should become a story in the product backlog and dealt with just like any other story (estimate in Story Points, prioritized by the PO, etc). The purpose of this is to make them visible to the Product Owner and force him/her to prioritize customer reported defects in relation to new functionality. This is consistent with Ken (Schwabers) Squirrel Burger story.

Known bugs found this sprint (for software in development) need be fixed before a Story can be considered "Done." And, should only be accepted by the PO once it's "Done."

2. In my experience, capacity planning is best done using "yesterdays weather" (http://c2.com/cgi/wiki?YesterdaysWeather) using story points. I would strongly recommend against using hours for capacity planning, mainly because there is no correlation between developer hours and software in production (http://jeffsutherland.com/scrum/2007/10/why-time-sheets-are-lame.html).

>My company is often working on many simultaneous projects and having to juggle resources.

I may be reading this incorrectly, so please forgive me if I've taken it the wrong way ... If by "resources" you mean "people", then you're not doing scrum. Scrum teams are by definition dedicated to a team.

Best regards,
Kane Mar (CST, CSC, CSP ... etc)
http://KaneMar.com | http://www.linkedin.com/in/kanemar
http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival

Bugs and capacity planning

March 2, 2009 by jackMilunsky, 5 years 24 weeks ago
Comment id: 2315

Hi Kane,

Thanks for your contribution. I really appreciate this.

Personally I don't like converting Bugs to User stories. However your point is a valid one in that it could help with visibility with the Product Owners. In our organization, we are able to keep them separate and plan both user stories and bugs into a Sprint at the Sprint Planning meeting.

With respect to capacity planning. This is only done for the immediate sprint. And it's only there as a guide to see if you have enough resource time to complete the backlog items (inlcuding bugs etc) for the current Sprint. When you're Sprint planning you have to get down to hours and to track hours on the burndown so this needs to be as accurate as you can get it on any given day in a Sprint.

With respect to your last comment. I was wondering if someone would pick up on that. Technically you're right. Resources need to be dedicated. In our particular case resources are generally dedicated to a Sprint but they may be on a different Project next Sprint. It's just the nature of our business.

If you saw one of Jeff Sutherlands more recent video's .. he talks about rolling scrums .. part of his scaling scrum message .. is that developers may be working on multiple simultaneous sprints. I know it's hard to wrap ones head around this but it is possible. I wouldn't advocate this though.

Jack

>>If you saw one of Jeff

March 2, 2009 by Michael Dubakov (not verified), 5 years 24 weeks ago
Comment id: 2316

>>If you saw one of Jeff Sutherlands more recent video's .. he talks about rolling scrums .. part of his scaling scrum message .. is that developers may be working on multiple simultaneous sprints. I know it's hard to wrap ones head around this but it is possible. I wouldn't advocate this though.

It seems we are falling back to waterfall and multi-tasking...

Thinking

March 3, 2009 by Marble Host (not verified), 5 years 24 weeks ago
Comment id: 2319

This post got me me thinking about using a kanban system to manage various "projects" at the same time.

Our team would be working on a number of different projects/products at any given time and managing the throughput of them as a whole is sometimes difficult (due to lack of transparency.)
http://www.marblehost.com
Have you used kanban in a environment similar to that before /?

rolling sprints/multiple simultaneous projects

March 3, 2009 by jackMilunsky, 5 years 24 weeks ago
Comment id: 2320

This is really difficult to do. I would suggest only trying this in a very mature agile company. I still believe you get the best work from focused individuals. There's plenty data out there that proves multi-tasking is not good for productivity. But, depending on the type of projects, depending on the experience of the team and it's agile maturity you could do it. Kanban's pull system would definitely help with this.

Jack

Re: Bugs and capacity planning

March 13, 2009 by Kane Mar (not verified), 5 years 23 weeks ago
Comment id: 2362

Hi Jack,

>With respect to capacity planning. This is only done for the immediate sprint. And it's only
> there as a guide to see if you have enough resource time to complete the backlog items
> (inlcuding bugs etc) for the current Sprint.

Estimating in Story Points and using Yesterdays Weather will provide you with exactly this information without having to resort to capacity planning at the hourly level.

> When you're Sprint planning you have to get down to hours and to track hours on the
> burndown so this needs to be as accurate as you can get it on any given day in a Sprint.

Perhaps I don't fully understand ... why do you need to get to this level of detail? If you fully plan everyones time in a sprint, isn't that likely to lead to problems? If, for example, some piece of code takes 5 hours instead of 1 hour?

>If you saw one of Jeff Sutherlands more recent video's .. he talks about rolling scrums ..
> part of his scaling scrum message .. is that developers may be working on multiple
> simultaneous sprints. I know it's hard to wrap ones head around this but it is possible.

What you're referring to here is known as Scrum Type B and Type C. It's discussed in the white paper that served as a source of inspiration for scrum: "The New New Product Development Game" (Page 3, exhibit 1)

Jeff tried to introduce Type B and Type C directly into Scrum. Mostly notably through his blog posts in 2005 (here). This was debate back in 2006 and prompted Ken (Schwaber) to post his thoughts on the subject: "I've been following the threads about type N, A, B, C and advanced Scrum. Although these may represent the engineering, personnel, and product management practices that an organization adopts as a result of Scrum's inspect and adapt, they aren't Scrum."

His position has since been widely adopted throughout the Scrum trainer community, and over time Ken's original position appears to have solidified: "There is only one Scrum"

> I wouldn't advocate this though.

Neither would I! =)

Best regards,
Kane Mar
http://KaneMar.com | http://www.linkedin.com/in/kanemar
http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival

Estimating in Story Points

March 13, 2009 by jackMilunsky, 5 years 23 weeks ago
Comment id: 2364

Estimating in Story Points and using Yesterdays Weather will provide you with exactly this information without having to resort to capacity planning at the hourly level.

I agree that one should use yesterdays weather to determine how many user stories can be planned into a sprint. But once you have the User stories planned, you have to breakdown to the hour. How are you working with the burndown - in story points?

Personally if you don't do this breakdown, you're putting the team and project at risk. Breaking things down is fundamentally a planning and design task which you really need to do.

Thanks for pointing out the Type B and C scrum. I know it all to well. Appreciate you add that input.

jack

Hi Jamie & BrentI think it's

March 2, 2012 by NOnn (not verified), 2 years 24 weeks ago
Comment id: 21198

Hi Jamie & Brent
I think it's perfectly appropriate to compare Scrum (or agile. in general) to Chess. So did some of the very first articles on Scrume.g.. see The Chaos Strategy by LBS Raccoon in ACM Sigsoft Software Engineering Notes from August 1995. In that paper. though. Raccoon ultimately decided that it is more like the Oriental game of Go than Chess. b and you forfait sans engagement forfait illimite forfait sms illimite forfait mobile internet comparateur forfait bloque rio bouygues code rio orange rio sfr rio bouygues numero rio virgin calcul imc portabilite

You should however modify the

March 8, 2012 by William Cain (not verified), 2 years 23 weeks ago
Comment id: 21294

You should however modify the capacity to reflect reality (time spent in meetings, doing email, vacation etc) so this can get quite complicated. The best thing to do is to figure out what percentage of time per day you get real work out of the team on AVERAGE. Ferienhäuser Sondervig

I am frequently asked by

March 25, 2012 by Kelvin Butler (not verified), 2 years 21 weeks ago
Comment id: 21494

I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again: Forex Anbieter

Thanks Joel for posting this.

May 23, 2012 by JennyH876 (not verified), 2 years 12 weeks ago
Comment id: 22368

Thanks Joel for posting this. This is terrific and just what I needed for a project I have been working on for some time. Unfortunately. I haven't done as well as I would like in communicating effort. tasks and issues with my client. I am new to Agile and from what you have shown here it seems that I can take one step at a time. I really appreciate that you made this publicly available. rio orange

Awesome blog. I enjoyed

September 1, 2012 by Anonymous (not verified), 1 year 50 weeks ago
Comment id: 23708

Awesome blog. I enjoyed reading your articles. This is truly a great read for me. I have bookmarked it and I am looking forward to reading new articles. Keep up the good work!
best free Android apps

Good post. Will follow your

September 13, 2012 by Anonymous (not verified), 1 year 48 weeks ago
Comment id: 23854

Good post. Will follow your blog. Hermes Birkin

Assume that the team is

January 11, 2013 by Anonymous (not verified), 1 year 31 weeks ago
Comment id: 25369

Assume that the team is consistently committing to 20 story points and 5 points worth of defects. In iteration 5 they have no defects to work on (yay!), if defect points don't contribute toward velocity, they are going to commit to 20 points of story work. They will be done early and it won't be immediately apparently what happened. If the team responds at the next sprint planning meeting and selects more work, but this time has a defect to work on, they are going to fall short of their commitment.
katalog stron
salon sukien ślubnych warszawa
katalog stron
suknie ślubne
http://www.e-zwd.pl
http://www.e-zawady.pl

Time to fix bugs therefore,

February 11, 2013 by Rdnnis Dgefb (not verified), 1 year 27 weeks ago
Comment id: 26230

Time to fix bugs therefore, should come out of your teams available capacity. So when one schedules bugs to be fixed, bugs should be estimated just like you do with tasks on the sprint backlog. Developers must therefore determine for each bug scheduled, the hours remaining to complete the bug daily. And this WILL be reflected in the daily burn-down along with tasks. Topfenknödel

I guess when you get to the

March 4, 2013 by roter (not verified), 1 year 24 weeks ago
Comment id: 26533

I guess when you get to the point where you feel its viable killtest ITILF2011 to be defect free then you come to the conclusion that original story points are in fact the measure of future defect estimation. That is you do not estimate defects because killtest JN0-343 it means you didn't actually correctly complete stories that had estimates marked as completed killtest 650-369 originally. If you are forced to consume those defects it gives you a more killtest 70-457 realistic picture of what your velocity really is...

My company is often working

March 4, 2013 by Anonymous (not verified), 1 year 24 weeks ago
Comment id: 26585

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we're considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don't, you will have an inaccurate measure of your teams productivity - something that will definitely lead to poor planning and late deliveries. (....read more)

Time to fix bugs therefore, should come out of your teams available capacity. So when one schedules bugs to be fixed, bugs should be estimated just like you do with tasks on the sprint backlog. Developers must therefore determine for each bug scheduled, the hours remaining to complete the bug daily. And this WILL be reflected in the daily burn-down along with tasks.
e-papierosy
e-papierosy
e-papierosy
e-papierosy
e-papierosy
e-papierosy
e-papierosy
e-papierosy

Business Cards

April 19, 2013 by Katty Chopra (not verified), 1 year 17 weeks ago
Comment id: 27079

Awesome blog. I enjoyed reading your articles. This is truly a great read for me.and I am looking forward to reading new articles. Keep up the good work!
I was very pleased to find this site. I wanted to thank you for this great post!! I am definitely enjoying every little bit of it and I have bookmarked it Business Cards

HP2-E45 || HP2-K24 || HP2-E43

May 2, 2013 by shonteat (not verified), 1 year 15 weeks ago
Comment id: 27347

Mostafa

May 21, 2013 by شات بنات مصر (not verified), 1 year 13 weeks ago
Comment id: 27734

Good man And Ty

شات مصرى
دردشة مصرية
دليل مواقع
مركز تحميل الصور
منتدى
منتديات
موقع
شبكه
شبكة
منتدى بحبو
منتديات بحبو
شات
دردشة
شات مصر
نكت 2013

رسائل عتاب 2013
رسائل حب
رسائل حب 2013
رسائل رومانسية 2013
رسائل قصيرة
دهانات حوائط
ديكورات 2013
اسماء بنات
اسماء بنات 2013
غلاف فيس بوك 2013
ازياء محجبات 2013
صور بنات كول 2013
خلفيات ايباد 2013
صور حزينة 2013
صور حزينة
صور حزن
صور رومانسية 2013
صور بنات 2013
خلفيات واتس اب
توبيكات واتس اب
توبيكات
برود كسات
صور سيارات 2013
صور سيارات
صور حب
صور حب 2013
صور حب 2013
صور حب
صور حب وغرام
صور حب
رسائل 2013
رسائل
رسائل حب 2013
رسائل حب
خلفيات جالكسى
صور بنات 2013
صور بنات
خلفيات ايفون 2013
خلفيات ايفون
خلفيات ايباد 2014
خلفيات ايباد 2013
خلفيات ايباد
2013 خلفيات ايباد بنات
خلفيات ايباد بنات
صور بنات ايمو
صور ايمو 2013
صور ايمو
ازياء
ازياء 2013
ازياء 2014

نكت
نكت مصرية
نكت مساطيل
صور لالى وشيخار
صور شيخار
صور لالى
صور مسلسل لالى
صور بنات للمسن
صور بنات للياهو
صور كريم وفاطمة
صور فاطمة وكريم 2013
صور للمسن 2013
صور شباب
صور حزينة
صور حب
صور غرام
صور انجلينا جولى
صور انجلينا جولى 2013
صور غرام 2013
صور حب 2013
صور رومانسية
صور رومانسية 2013
صور
صور 2013
صور 2014
صور 2015
تردد القنوات الفضائية
تردد القنوات
تردد قناة ميلودى دراما
تردد قناة ميلودى دراما 2013
تردد قناة ميلودى دراما 2014
تردد قناة النهار
تردد قناة النهار 2013
تردد قناة المصارعة
تردد قناة المصارعة 2013
تردد قناة زى الوان
تردد قناة زى الوان 2013
تردد قناة ام بى سى 2013
تردد قناة توب موفيز 2013
تردد قناة توب موفيز
تردد قناة top movies
تردد قناة توكتوك 2013
تردد قناة توك توك
صور بنات
صور بنات 2013
صور بنات 2014
تردد قناة روتانا سينما
تردد قناة روتانا سينما 2013
تردد قناة rotana cinema
تردد قناة دريم 2
صور سيارات 2013
صور ميسى
صور مسيى 2013
صور ميسي
صور ميسي 2013
صور ميسى 2014
برامج
برامج 2013
برامج مجانا
تحميل برنامج البالتوك
تحميل برنامج داون لود مانجر
تحميل برنامج دون لود مانجير 2013
تحميل برنامج اوفيس 2013
تحميل برنامج اوفيس
تحميل برنامج الورد
تحميل برنامج الورد 2013
تحميل برنامج كاسبر سكاى
تحميل برنامج كاسبر سكاى 2013
تحميل فايرفوكس
تحميل متصفح فايرفوكس
تحميل فايرفوكس 2013
تحميل ماسنجر هوتميل
شرح عمل اميل اسكاى بى
تحميل برنامج نت فروم ورك
تحميل برنامج سكاى بى
قسم فيس بوك
تحميل برنامج تشارلز
تحميل برنامج تشارلز 2013
بوستات فيس بوك
بوستات فيس بوك 2013
صور غلاف فيس بوك
صور غلاف
صور بروفايل الفيس بوك
غلاف فيس بوك
غلاف فيس بوك 2014
كفرات فيس بوك 2015
غلاف فيس بوك 2013
صور غلاف
غلاف فيس بوك 2014
اغلفه فيس بوك
تحميل برنامج سوبرا
تحميل برنامج سوبرا 2013
شرح عمل اميل ياهو
شرح عمل اميل ياهو بالصور
تحميل برنامج لفتح اكتر من اميل ياهو
تحميل ياهو
قسم للياهو
قسم للدردشة
تحميل برنامج هايدى ايزى
تحميل برنامج الويب برو
برنامج فلود
برامج موبايل
برامج موبايل 2013
برامج جوال
برامج الاختراق
ثيمات موبايل
ثيمات موبايل 2013
خلفيات موبايل 2013
العاب موبايل
العاب جوال
العاب موبايل 2013
العاب جوال
اخر اخبار العالم
منتدى الحب والرومانسية
قسم مدونات الاعضاء
حلال مشاكل الحب
تحميل برنامج الفوتوشوب cs5
تحميل برنامج الفوتوشوب
تحميل برنامج الناشر الصحفى
تحميل برنامج الناشر الصحفى 2013
قسم الفوتوشوب
شروحات الفوتوشوب
شرح اضافة الخطوط فى الفوتوشوب
شرح عمل مخطوطه ثرى دى
مستلزمات الفوتوشوب
تحميل تدرجات فوتوشوب
تحميل تدرجات فوتوشوب 2013
تحميل خطوط 2013
تحميل خطوط عربية 2013
تحميل خطوط للفوتوشوب
تحميل فرش 2013
تحميل فرش للفوتوشوب
صور مقصوصه
صور مقصوصه 2013
تحميل استايل فوتوشوب 2013
تحميل خطوط 2014
تحميل اكشن 2013
قسم حواء
طبخ 2013
طبخ
تعلم الطبخ
ازياء
ازياء 2013
ازياء عبايات
ازياء عبايات 2013
ازياء 2014
ازياء فساتين
ازياء فساتين 2013
ازياء اليسا
ازياء فساتين 2014
ازياء فساتين 2015
ازياء بنات
ازياء بنات 2013
ازياء بنات 2014
ازياء بنات
ازياء بنات 2015
فساتين حوامل
ازياء رجال
ازياء رجال 2013
ازياء شباب
ازياء شباب 2013
ازياء رجال
ازياء محجبات
ازياء محجبات 2013
ازيا محجبات
فساتين محجبات
ازياء محجبات 2013
ازياء محجبات 2013
العناية بالجمال
تسريحات
تسريحات 2013
ميك اب
ميك اب 2013
مكياج
مكياج 2013
ديكورات
ديكورات 2013
احدث ديكورات
ديكورات غرف نوم
ديكورات غرف نوم 2013
شعر
اشعار
شعر 2013
قصائد
قصائد 2013
قصيده
قصايد
خواطر
خواطر 2013
قصائد حب 2013
قصص
قصص 2013
روايات
روايات 2013
العاب 2013
العاب
شفرات جاتا
شفرات جاتا 2013
تحميل لعبة بيس 2013
تحميل لعبة pes 2013
تحميل لعبة بيس
تحميل لعبة المصارعة
تحميل لعبة المصارعة 2013
تحميل لعبة جنرال زيرو اور
تحميل لعبة جنرال زيرو اور 2013
تحميل لعبة جاتا
تحميل لعبة جاتا 2013
تحميل لعبة جاتا شبكة
تحميل لعبة زوما
تحميل لعبة زوما 2013
تحميل لعبة سلاحف النينجا
تحميل لعبة سلاحف النينجا 2013
تحميل العاب فلاش
تحميل العاب فلاض 2013
لعبة جاتا 2013
تحميل العاب
كونكر
كونكر تهيس
كونكر 2013
كونكر تهيس 2013
شرح عمل سيرفر كونكر تهيس
اسماء جيلدات 2013
اسماء اكونتات
شرح لعبة كونكر
تحميل لعبة كونكر
سيلك رود
شحن سيلك مجانا
تحميل لعبة سيلك رود
كروس فاير
هاكات كروس فاير
اخبار الرياضة
العاب جوال 2013
نغمات موبايل
نغمات جوال
نغمات
نغمات موبايل 2013
نغمات جوال 2013
نغمات 2013
رنات
رسائل
رسائل حب
رسائل حب 2013
رسائل رومانسية
رسائل رومانسية 2013
رسائل رومانسية 2014
رسائل اسلامية
رسائل اسلامية 2013
رسائل عشاق
رسائل عشاق 2013
رسائل حزن
رسائل حزن 2013
رسائل حزينة
رسائل حزينة 2013
رسائل غرام
رسائل غرام 2013
رسائل منوعة
رسائل دعاء
رسائل دعاء 2013
مسجات
مسجات 2013
رسائل قصيرة
رسائل حب قصيرة
رسائل قصيرة 2013
رسائل جوال
رسائل موبايل
رسائل جوال 2013
خلفيات ايفون
خلفيات ايفون شبابى
خلفيات ايفون شبابى 2013
خلفيات اي فون حزينة
خلفيات ايفون حزن 2013
خلفيات ايفون 2014
iphone wallpapers Romantic
خلفيات ايفون رومانسية
خلفيات ايفون رومانسية 2013
خلفيات ايفون بنات
خلفيات ايفون بنات 2013
خلفيات اي فون بناتى
خلفيات ايفون
خلفيات اي فون
خلفيات ايفون 2013
خلفيات ايفون 2015
iphone wallpapers girls 2014
خلفيات اي فون بنات 2014
خلفيات ايفون
خلفيات ايفون بناتي
خلفيات ايفون رومانسية
خلفيات ايفون رومانسية 2013
خلفيات للايفون
خلفيات ايفون 2014
خلفيات ايفون اسلامية 2013
خلفيات ايفون حيوانات 2013
خلفيات اي فون حيوانات
خلفيات ايفون منوعة
خلفيات ايفون منوعة 2013
خلفيات بلاك بيرى
خلفيات بلاك بيرى 2013
خلفيات بلاك بيري 2013
خلفيات بلاك بيري
خلفيات بلاك بيرى 2015
خلفيات بلاك بيرى 2014
خلفيات بلاك بيرى شباب 2013
خلفيات بلاك بيرى شبابية 2013
خلفيات بلاك بيري شبابى 2013
خلفيات بلاك بيرى عشق
خلفيات بلاك بيري عشاق 2013
خلفيات بلاك بيرى منوعة
خلفيات بلاك بيرى حب
خلفيات بلاك بيرى حب 2013
خلفيات بلاك بيرى بنات
خلفيات بلاك بيرى بنات 2013
خلفيات بلاك بيرى رومانسية
خلفيات بلاك بيرى رومانسية 2013
خلفيات بلاك بيرى اطفال
خلفيات ايباد
خلفيات اي باد 2013
خلفيات ايباد اطفال
خلفيات ايباد اطفال 2013
خلفيات ايباد شباب
خلفيات ايباد شباب 2013
خلفيات ايباد 2014
خلفيات ايباد منوعة 2013
خلفيات ايباد حزن
خلفيات ايباد حزن 2013
خلفيات ايباد حزينة
خلفيات ايباد حزينة 2013
خلفيات ايباد بنات
خلفيات ايباد بنات 2013
خلفيات ايباد 2016
رمزيات ايباد
رمزيات ايباد 2013
خلفيات جالكسى
خلفيات جالكسى 2013
خلفيات جالكسى 2014
خلفيات جالكسى 2015
خلفيات جالكسى اسماء
خلفيات جالكسي
خلفيات جالكسى 2016
خلفيات جالكسى اطفال 2013
خلفيات جالكسى منوعة
خلفيات جالكسى منوعة 2013
خلفيات جالكسى بنات
خلفيات جالكسى بنات 2013
مسلسلات
مسلسلات 2013
مشاهدة الافلام اونلاين
افلام عربية
افلام عربية 2013
افلام عربى
افلام عربى 2013
افلام اجنبى
افلام اجنبى 2013
افلام اجنبية
افلام اجنبية 2013
افلام هندية
افلام هندية 2013
مسرحيات
مسرحيات 2013
افلام كرتون
افلام كرتون 2013
البومات 2013
اغانى
اغانى 2013
اغاني 2014
اغانى اجنبية
اغانى اجنبى
اغانى اجنبية 2013
اغانى اجنبى 2013
اغانى شعبى
مهرجانات
اغانى شعبى 2013
مهرجانات 2013
اغانى شعبى 2014
مهرجانات 2014
كلمات اغانى
كلمات اغانى 2013
كلمات اغانى 2014
كلمات اغنية
خريطة المنتدى
خلاصة المنتدى
Rss
ارشيف المنتدى
الارشيف

his article has me looking

June 2, 2013 by Anonymous (not verified), 1 year 11 weeks ago
Comment id: 28176

his article has me looking from the past and only now I found it. Improve the quality of your articles and continue to create a more interesting. Korek Api Gas Fighter Indonesia | Margahayuland

000-575 exam || 000-080 exam

June 3, 2013 by Kim (not verified), 1 year 11 weeks ago
Comment id: 28330

This bus adventure seem to be

February 26, 2014 by Anonymous (not verified), 25 weeks 1 day ago
Comment id: 31514

This bus adventure seem to be relevant and interesting one. I think if there is touch of adventure in the bus tour then nothing can stop the rip to be exceptional one.
http://etnisjawa.blogspot.com/2014/01/agen-texas-online-indonesia-terpercaya.html
Agen Texas Online Indonesia Terpercaya
Alfamart official partner merchandise FIFA piala dunia Brazil 2014
Cipto Junaedy

مصطفى

March 3, 2014 by منتدى (not verified), 24 weeks 2 days ago
Comment id: 31739

اهلا وسهلا بكم في
تحميل برامج مجانية
حيث نقدم لكم مجموعة من البرامج وهى عباره عن
برنامج تحويل الصور الي كارتون
وهو يعمل على تحويل الصور الى كارتون و كما يوجد افيرا مكافح الفيروسات
تحميل افيرا مكافح الفيروسات
و افضل
برنامج لحماية الفلاش ميموري من الفيروسات
و اجمل برنامج تعديل فيديو
برنامج للتعديل على ملفات الفيديو

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com