How to deal effectively with short 10 day sprints without feeling pressure?

[Satyaprakash Joshii]

We are having 10 day Agile sprints and give demo of the work after end of each sprint. After 10 days the next sprint starts. We are told the Agile User Stories to be added in this sprint.  Time is spent on exploring how to do task of a particular user story , doing the coding and then testing it is working fine. Like this there are many user stories in a sprint. At the end of sprint some user stories gets left unfinished or the ones not started at all. Then the next sprint starts pending user stories are added to the sprint, new user stories are added. If someone takes 2 day leave in the sprint then it is even lesser working days for him(8 days) to accomplish so much. Sometimes on weekends , I feel if I work today I will finish some of the tasks before the sprint ends.  All this leads to a lot of continuous pressure. How to deal with all this effectively without feeling pressure?

[Tim Moores]

Satyaprakash Joshii wrote: We are told the Agile User Stories to be added in this sprint.

That is wrong. The team buys into what gets done in a sprint - if someone else decides it, that is not Scrum, and the scrum master needs to reject it.

[Jeanne Boyarsky]

Have you brought this up at your team retrospective? You are having retrospectives right? And the team is empowered to change things? I say this tongue in cheek. There are lots of companies that pretend to do Scrum, but are using it as a weapon.

25% of my job is to be the Scrum Master on my team. One of the things we do is have a spreadsheet to calculate velocity. It uses historical data from the last three sprints normalized for how many hours of available for work that sprint. This means that if there are vacations in the sprint, our velocity is lower. As it should be.

Also keep in mind that the TEAM committed to doing the work. It's not your responsibility to be a hero. Scrum is about sustainability. If you work weekends, it will become expected. And not sustainable.

We are told the Agile User Stories to be added in this sprint.

The Product Owner is supposed to provide a prioritized list of stories. He/she doesn't determine how many are in the sprint. My Product Owner is good about this. He looks sad when something he wants doesn't make it in. But he respects the process.

[Satyaprakash Joshii]

For every sprint the pattern is such that we are asked to add more user stories then we estimate for and at the end of sprint in reports whatever is not completed comes in Red.I want to know that if  this keeps repeating for many months what would be the result of this?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:For every sprint the pattern is such that we are asked to add more user stories then we estimate for

Asked by whom? The product owner? And who pushs back?

Satyaprakash Joshii wrote:In reports whatever is not completed comes in Red.

That sounds like a project management thing. Scrum has the concept of a sprint goal not being met. I don't know what red is. Also, a Scrum team is supposed to be adjusting how much they commit to based on evidence of what they have done. So if stuff is "red", that means the next sprint should have less story points.

Satyaprakash Joshii wrote:I want to know that if  this keeps repeating for many months what would be the result of this?

Burnout. Do you have retrospectives? If so, can you bring this issue up there?

It sounds like your company isn't really doing Scrum and just using some of the terminology. But calling them out on that might force the conversation.

[Satyaprakash Joshii]

Asked by whom? The product owner? And who pushs back?

Architect.

That sounds like a project management thing. Scrum has the concept of a sprint goal not being met.

Yes exactly. Some sprint goals are not met at end of every sprint and one has to give explanation of why?

sounds like your company isn't really doing Scrum and just using some of the terminology.

Is it a good idea that when they are adding tasks for the Spring and they are about to say why so much time for this work which looks less from higher level but looks bigger on knowing implementation details, show them the work break down structure and tell them see this all adds up to those many hours so it will take this much time? But in that case how would you be knowing the work breakdown structure on the day sprint starts when every moment until the day before you were trying to complete the previous sprint tasks which did not even complete. Work breakdown structure would come when you have a day to think about the what would be the low level tasks involved for the user story.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:
Asked by whom? The product owner? And who pushs back?

Architect.
These are different questions. Is the architect asking or pushing back?

Satyaprakash Joshii wrote:Yes exactly. Some sprint goals are not met at end of every sprint and one has to give explanation of why?

Well you know why. Someone is dumping too much work in the sprint. I think the key is not agreeing to it at sprint planning. If the team says, there is too much work in the sprint and doesn't complete it, that is what you say. Then there can be a discussion about what commitment means. Because you delivered what you expected; less than the work in the sprint.

Satyaprakash Joshii wrote:

sounds like your company isn't really doing Scrum and just using some of the terminology.

Is it a good idea that when they are adding tasks for the Spring and they are about to say why so much time for this work which looks less from higher level but looks bigger on knowing implementation details, show them the work break down structure and tell them see this all adds up to those many hours so it will take this much time? But in that case how would you be knowing the work breakdown structure on the day sprint starts when every moment until the day before you were trying to complete the previous sprint tasks which did not even complete. Work breakdown structure would come when you have a day to think about the what would be the low level tasks involved for the user story.

Do you use planning poker cards to estimate as a team? If so, all of the developers saying it takes that much time, it probably does. A high level estimate doesn't take a work breakdown structure.  

Also, you have data on how long things took in previous sprints. Point to that.

[Junilu Lacar]

Late to the party but what OP describes is exactly why Agile these days isn't what it was intended to be and enthusiasm for it is dying in many places (some even consider it to be Dead already). No matter what you choose to call it, I certainly wouldn't call it "Agile", that way of working is just not what the originators of the Manifesto envisioned. That's what they were trying to get away from.

[salvin francis]

Jeanne Boyarsky wrote:There are lots of companies that pretend to do Scrum, but are using it as a weapon.

Very powerful words. I stand by this !

[Junilu Lacar]

Satyaprakash Joshii wrote:For every sprint the pattern is such that we are asked to add more user stories then we estimate for and at the end of sprint in reports whatever is not completed comes in Red.I want to know that if  this keeps repeating for many months what would be the result of this?

If I were in that situation, the immediate result would be me polishing up my resume and getting the heck out of there as soon as I can. If I had money socked away so that I could survive until my next job came along, I would be out the door immediately.

If you are unfortunately unable to extricate yourself from a toxic environment like that, the result would be declining morale in the development team, declining productivity, increasing number of bugs, more pressure from management to get things done, and an ever increasing downward spiral into the pits of hell. That's what you have to look forward to in the next few months unless somebody stands up and says "Enough of this madness! This isn't what Agile is supposed to be!"

[Satyaprakash Joshii]

Thanks. I have 2 doubts. Is it a good strategy that when ever you are asked the time estimate for a user story, show them the work break down structure into small tasks and show that it has so many small small tasks and thus it will take this much of time . But the estimate is asked on the first day of the sprint. At that time when you have just heard about the user story , how will you immediately do the work break down structure and thus the estimate during the sprint meeting?

[Satyaprakash Joshii]

Thanks

These are different questions. Is the architect asking or pushing back?

He says the put those many user stories in a sprint. He says it is doable.

Then there can be a discussion about what commitment means.

What does this mean?

A high level estimate doesn't take a work breakdown structure.  

I know only one way of giving estimate. Break the task into small small tasks you can think of. Add estimate of this time. If design is not decided yet, add a day for design and add a day for testing. How to give high level estimate instead of this?

[Junilu Lacar]

There are many anti-patterns you are hinting at with your questions and statements.

One anti-pattern is spending so much effort in estimating. First of all, why do you need to get so detailed? An estimate is, by definition, not going to be very accurate. It's a "give or take a few" number.

An estimate is not a commitment either. If you estimate that something will take you two days to complete and it actually takes you three or four days to complete, then most probably that's because of one or more of the following:

1. You didn't fully understand the problem and/or the extent of the work to solve the problem
2. You encountered technical problems that you did not anticipate and could not easily resolve
3. There was a dependency that you had to wait on that kept you from completing the work in the time you thought it would take

Most of the time, it's 1 and/or 2, and less often #3.

It sounds like your managers/leaders are just playing a numbers game, driven more by the metrics and getting some desired "numbers" rather than actually helping the team produce well-written software that meets quality and functional requirements. That's a toxic environment and if it were me I would look for a way to get out of it as soon as possible.

[Junilu Lacar]

If your only goal is self-preservation, then I would say you are going to have to play their game and try to push back on whatever "estimates" are imposed on you. Tell them that it's going to take you 2 times longer than what the "architect" gives as the estimate.  If you can't do that, then at least ask the architect for help. Say that you don't know how to complete the item in the time he said it would take and ask him for ideas on how he would approach the work so that it can be done in the time he said it would be.  If at all possible, ask the architect to pair with you and show you exactly how he would do the work.

Again, this is just me, but I would actually ask him to show me how he would do it. I might even challenge him to prove that he can meet his own "estimate" (choose something that is more challenging for him to do) by actually taking on the work himself and completing it in the time he said it could be done.

[Satyaprakash Joshii]

It sounds like your managers/leaders are just playing a numbers game

For example : Some developer will do the same thing in less number of days than me to complete the same thing and some developer may take more number of days than me to complete the same thing.. In such a case how to conclude whether the estimate managers are giving is correct or wrong for me?

[Junilu Lacar]

The question you should really ask is "Why are managers/leaders who are NOT doing the work giving the estimates?"  Estimates, if they are to be given at all, should be made by the people who are going to do the actual work. If you are way off on your estimates, then you need to figure out why. What was it about the work that you didn't take into account? What kind of problems did you encounter that required more time?

Again: Only people who are actually going to do the work should be giving estimates, if any estimates are to be given all.  If those managers and the architect are not working on completing the items themselves, then they have no business in giving estimates, much less dinging people for not being able to complete the work in the time they thought it would take.  I would not stand by and just take that kind of abuse. And it is abuse.

[Junilu Lacar]

Satyaprakash Joshii wrote:In such a case how to conclude whether the estimate managers are giving is correct or wrong for me?

That's easy: You don't.  

Again, YOU should be giving the estimate if YOU are going to do the work. The only time THEY can give estimates is if THEY are doing the work.

Also, an estimate is NOT SUPPOSED to be correct or wrong.  The best you should expect of an ESTIMATE is that it is either "in the ballpark" or "way off base" or somewhere in between.

[Satyaprakash Joshii]

One developer may be fast and productive.He would be giving a correct estimate of for example 3 days to complete the work. For the other developer of same experience level, the estimate may be 6 days because he is not as fast and productive as the first person. So in such a case how would the estimate be validated ? For example for this same work if some third person would have said 10 days as estimate, then what?

[Junilu Lacar]

And for the same task, it may take a developer 2 days to complete it in April but it takes the same developer 4 days to complete the same kind of work in May. This is entirely possible, which is why I keep saying, it's the person who does the work who should be giving an estimate if estimates to be used in any way meaningful.

If you're doing Scrum, stories are supposed to be estimated in terms of amount of effort. This is NOT the same as the time it will take to finish. The classic explanation for the difference is the example of moving a pile of dirt from one place to another.  

A team can estimate that moving a big pile of dirt from one place to another will take X amount of effort. That is, let's say they were to work under the constraint that they had to use a specific wheelbarrow and specific shovel, then they may look at the pile of dirt, estimate that it has about 10 cubic meters of dirt. Then they look at the wheelbarrow and estimate that it can hold about 0.3 cubic meters of dirt. They look at the shovel and estimate that it can pick up about 0.02 cubic meters of dirt at a time.  They do some math and come up with an approximation of how many shovels it would take to fill up the wheelbarrow and how many times you'd need to fill the wheelbarrow, wheel it to the where you're moving the dirt, dump it, then wheel it back for the next load.

The workers, of course, know that each of them will shovel at a different rate, and will probably fill the wheelbarrow with different amounts depending on their strength and ability to sustain the work to completion. If someone is big and strong enough to fill it to more than 0.35 cubic meters of dirt, that's fine. But someone smaller and not as strong may only fill it up to 0.25 cubic meters and would therefore have to take more trips to move the whole pile of dirt.

All this means is that while they may be able to estimate the amount of effort it might take to move the dirt, the actual TIME it will take to move the dirt will vary, perhaps greatly, depending on the strength and stamina of the person who is actually doing the work. And then you have to deal with unanticipated problems like if someone starts doing the work and then discovers that the bottom half of the pile of dirt has hardened, thus making it more difficult to shovel, then of course it will take longer. Now their initial estimation of the amount of effort involved will be off by a factor of difficulty in shoveling the dirt.

Bottom line is, I think that your need to get an estimate in days, driven by the demands of your manager and architect, unrealistic because whatever number that is, it will be totally subjective and subject to wide variations depending on the person who will actually do the work.

[Campbell Ritchie]

Satyaprakash Joshii wrote:. . .

Then there can be a discussion about what commitment means.

What does this mean? . . .

Maybe that you are going to tell management that you have done as much as you can and any more would jeopardise the quality of the product. Maybe that management all have pointy hair. Or maybe that you should follow Junliu's suggestion to...

. . . [get] the heck out of there as soon as I can.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:He says the put those many user stories in a sprint. He says it is doable.

Then he should do it. If I tell you that you have to create 100 screens in a week, that isn't possible. Just because I claim it is doable, doesn't make it possible.

Satyaprakash Joshii wrote:

Then there can be a discussion about what commitment means.

What does this mean?

He's making an estimate. You are saying you disagree (rather than committing to it.) When it doesn't happen in the estimated time, it is his responsibility, not yours.

Satyaprakash Joshii wrote:I know only one way of giving estimate. Break the task into small small tasks you can think of. Add estimate of this time. If design is not decided yet, add a day for design and add a day for testing. How to give high level estimate instead of this?

There's other ways of estimating. For example, think of the actuals for similar tasks in the past. Another ways, is planning poker cards in Scrum. if the architect says something will take 2 days and everyone else says 5, that gets a discussion going.

[Campbell Ritchie]

Jeanne Boyarsky wrote:. . . When it doesn't happen in the estimated time, it is his responsibility, not yours. . . .

In which case you would do well to document the fact that you warned management it wasn't possible.

[Satyaprakash Joshii]

This is entirely possible, which is why I keep saying, it's the person who does the work who should be giving an estimate if estimates to be used in any way meaningful.

How is it validated that the estimation is not too high. For example a developer may feel that he may be able to do the task in 5 days. Now he can say 5 days but what if thinks let me say 10 days. Saying 10 days is the wrong thing to do in this case. Saying 2 days is also wrong thing to do in this case. Saying 5 is the right thing to say. What if he decides to say 10 days then how will this be validated in this case?

[Satyaprakash Joshii]

Jeanne Boyarsky wrote

A high level estimate doesn't take a work breakdown structure.  

If the below is a wrong strategy then what is the correct strategy to answer when asked for the estimate during the meeting on first day of the spring when you have just heard the name of user story and not even know the details?

Strategy: Whenever you are asked the time estimate for a user story, show them the work break down structure into small tasks and show that it has so many small small tasks and thus it will take this much of time . But the estimate is asked on the first day of the sprint. However , at this time you would  have just heard about the user story and would be knowing the work break down structure only later and not during the sprint meeting.

thanks

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:How is it validated that the estimation is not too high. For example a developer may feel that he may be able to do the task in 5 days. Now he can say 5 days but what if thinks let me say 10 days. Saying 10 days is the wrong thing to do in this case. Saying 2 days is also wrong thing to do in this case. Saying 5 is the right thing to say. What if he decides to say 10 days then how will this be validated in this case?

Developers are hopelessly optimistic. If the developer thinks it will take 5 days, it will probably take 6 or 7.

Satyaprakash Joshii wrote:If the below is a wrong strategy then what is the correct strategy to answer when asked for the estimate during the meeting on first day of the spring when you have just heard the name of user story and not even know the details?

It's not that a work breakdown structure is wrong. It's good in waterfall or when precise estimates are needed. In a shorter period of time (aka a sprint), the effort in getting a more accurate estimate is time wasted. I suggested two other ways of estimating in this thread:

Jeanne Boyarsky wrote: There's other ways of estimating. For example, think of the actuals for similar tasks in the past. Another ways, is planning poker cards in Scrum. if the architect says something will take 2 days and everyone else says 5, that gets a discussion going.

[Junilu Lacar]

Think about this way:

What value do you derive from giving "precise estimates" (an oxymoron, in my opinion)? How does spending more than a minute agonizing over whether your estimates are "precise" add value for your customer? If you could make your estimates more precise, what would that change for the better, if anything?

In my opinion, it DOESN'T add value nor does it make any difference in managing your project. You'd still have to deal with unforeseen events that would make reality differ from your estimates. If they were unforeseen events, then how could you have included them in your estimates? If you added allowances for unforeseen events, then how does that help you if those unforeseen events don't happen? How does it help you if those unforeseen events have a greater impact on your ability to finish "on time" such that the allowances you made up front are also way off? Are you now going to estimate how much allowance you need? Do you need your allowances to be precise as well? From there, it's turtles all the way down, you know.

[William Barnes]

They are just using the word "Agile" as a way of piling too much work on you.  You can push back, but if management wants to just pile work on you, it doesn't matter what they call the development process.  Sounds like you should start looking for another job.  Good luck.

[Satyaprakash Joshii]

What value do you derive from giving "precise estimates" (an oxymoron, in my opinion)? How does spending more than a minute agonizing over whether your estimates are "precise" add value for your customer? If you could make your estimates more precise, what would that change for the better, if anything?

This makes sense. Thank You.

[Satyaprakash Joshii]

There can be 2 cases:

1) Team has been given too many user stories for the short sprint.

In this case the development team can give the actual estimate and say only these many would be completed in this sprint.

2) Team has been given the estimates which look correct.

3) Team has been given correct estimates but some developer may think the number of user stories he is asked to complete in the sprint is more because he is not a productive resource and it is because of his inefficiency.


We have discussed about cases 1 and 2. How would it be determined in case situation  that the case is not 3.

[Junilu Lacar]

The phrase "The team has been given..." is key here.

Agile teams are self-organizing. Part of self-organizing means they are responsible and they are transparent. Giving the teams the things they are "supposed" to work on and deliver runs counter to letting them self-organize. So, when a team is given their work the way you have been describing, they lose the aspect of self-organization that allows them to take responsibility and be transparent because what's really happening is that the work as well as the commitment to finish that work is being imposed upon the team rather than them owning the work and taking on the responsibility of finishing it.

In other words, there is a level of dishonesty and non-transparency created when work is given to (forced upon) a team and they willingly accept that work. It's even worse when they reluctantly or begrudgingly accept that work.

It's even worse when there is nothing they can do to try to bring some honesty and transparency back into the whole situation. That is what is most discouraging. That is what you're going through right now. You are looking for a way to reconcile the irrationality of the whole situation with your desire to be honest and transparent. That is laudable.

Unfortunately, you have a bit of Broken Elephant Syndrome and you're not seeing all the options for dealing with this situation that are available to you. Instead, you only see the option that this architect and manager are giving you. So, you are trying to appease them, play by their rules that they have imposed on you, and find a middle ground.

There is no middle ground nor is there any way you can appease these people, at least not in the way you are looking to do it. They have to change their mindset and meet you in "the middle". Only in that middle ground where the team can willingly and honestly agree to the work they will own can there be any hope of bringing back rationality, transparency, honesty, and integrity into the situation.

It has been pointed out several times in a few different ways in this thread already: Whoever gives the estimates should also do the work. Conversely, if you are not going to do the work, you have no right whatsoever to impose your own estimates on anyone who actually will.

[Junilu Lacar]

Satyaprakash Joshii wrote:"correct estimates"

Again, a symptom of Broken Elephant Syndrome. Estimates can turn out to be good or poor. Only after the fact, when the work is done, is it even remotely rational to say an estimate was "correct" and even then, "correct" is a poor choice of words.

What are you really trying to get when you estimate? Predictability. You are trying to predict the future state of being DONE or NOT DONE. You are really saying "I predict that we will be DONE in three days." If in three days the reality is that you are NOT DONE, there a few different ways you can look at it.  You can say your estimates were "wrong." Or you could also say your estimates "didn't take into account x, y, and z," or you could say that you "underestimated" or "overestimated."  (Of course, there are other ways to characterize estimates but let's just examine these three ways).

Saying that an estimate was "wrong" implies that there was some way that you could have gotten it "right." In your situation, how in the world could you have gotten the estimate right? Can you actually predict the future? Can you foresee with your mind's eye things that are going to happen, things that any normal human being could not foresee?

When you say "the estimates did not account for x, y, and z happening," you're just being honest.

When you say "I underestimated (or overestimated) the effort needed," you're just being honest.

When you say "The estimates were WRONG," implying that there was a way to get them RIGHT, you're being totally dishonest.

[Junilu Lacar]

Satyaprakash Joshii wrote:some developer may think ... because he is not a productive resource and it is because of his inefficiency.

Broken Elephant.

You are actually more capable than you think you are right now.

[Satyaprakash Joshii]

I understand now that the ones doing the work should be giving the estimates. I also understand now also that I am showing Broken Elephant syndrome and the intent of honesty.

I have 3 doubts:

1) What value does developers giving the estimates themselves bring. The company wants maximum work to be done in minimum time. If the ones doing the work are allowed to give the estimates the pressure on them would be less and they might do less work in that much time instead of being on the toes and pushing themselves to do more.  I would certainly not want the second case but just trying to understand that what value does it bring to the company. Is it not a loss to the company that developers are not pushed to work faster and do more in  minimum time?

2) If developer while trying to do estimation thinks that he can do this task in 3 days but he thinks why to stress myself why not let me be bit relaxed and say the estimate as 5 instead of 3. How will this be validated?

3) After every sprint one has to provide reasons for every 'Sprint goal not met' in the writing. I write reasons such as "This user story had additional APIs", "This user story could not be taken because other user stories took more time to complete". What is the point in making the developer write the comment because any developer would always put some reason which is other than this fault or inefficiency (E.g I wasted time and worked slowly) which may be true for some developers out of many for sure?

[Jeanne Boyarsky]

I shared this thread with someone today.

Satyaprakash Joshii wrote:1) What value does developers giving the estimates themselves bring. The company wants maximum work to be done in minimum time. If the ones doing the work are allowed to give the estimates the pressure on them would be less and they might do less work in that much time instead of being on the toes and pushing themselves to do more.  I would certainly not want the second case but just trying to understand that what value does it bring to the company. Is it not a loss to the company that developers are not pushed to work faster and do more in  minimum time?

2) If developer while trying to do estimation thinks that he can do this task in 3 days but he thinks why to stress myself why not let me be bit relaxed and say the estimate as 5 instead of 3. How will this be validated?

People generally want to do the best job they can. They also tend to want to get raises and get promoted. If someone is "vacationing" at their desk, their teammates know. Their manager knows (if any good.) Note that this is different from a developer who "he is not a productive resource and it is because of his inefficiency. " (phrasing you used above.) The latter is generally teachable. Teammates pairing or training could correct that situation. There's also inefficiency due to assumptions. Which is one of the reasons planning poker works.

Suppose we are developing a pizza pie. I estimate 3 hours and you estimate 8. We talk about it and it turns out you were including time to go find pizza boxes but I know there is a stack over in the corner. This type of thing happens all the time. We find hidden assumptions. We find techniques to be faster. We share them as a team.

Satyaprakash Joshii wrote:3) After every sprint one has to provide reasons for every 'Sprint goal not met' in the writing. I write reasons such as "This user story had additional APIs", "This user story could not be taken because other user stories took more time to complete". What is the point in making the developer write the comment because any developer would always put some reason which is other than this fault or inefficiency (E.g I wasted time and worked slowly) which may be true for some developers out of many for sure?

My team starting doing this a few months ago.Not to be punitive like on your team. But to spot trends and things we can do better. It's viewed differently though because the idea came from a team member, we all agreed to it and we can stop at any time. Sometimes the reasons are things like pre-reqs not being available. Which helps us be more aware of those dependencies so we can deal with that type of thing earlier in the sprint or make it a prereq.

Sometimes the reason is that the task took longer than expected. (Or a higher priority task took longer than expected which didn't leave enough time for this one.) You know what happens then? We estimate more time for similar tasks. It's about learning.

Also, these things aren't news. They come up at the standup every day. In fact, sometimes that causes the actuals to go way up. Developer X realized a task was hard. So one or two people offered to help. Which means "their" tasks didn't get done but the more important one did. Reviewing them all together is just that. A review. So we can spot patterns in aggregate. Oh and we do this as a team. It's not that *Sam* didn't get *his* task done. It's that the team didn't get task Z done due to time.

Another benefit of this review is that it lets us see the number of tasks that didn't get done. It's far better to have one task not get done than 10% of each task.

Do you have a lazy developer on your team? That sounds like a problem for management to deal with directly.

[Junilu Lacar]

This is a good start:

Satyaprakash Joshii wrote:I understand now that the ones doing the work should be giving the estimates. I also understand now also that I am showing Broken Elephant syndrome and the intent of honesty.

But this is not:

I have 3 doubts:
...

The doubts you described all hint at an atmosphere of distrust and dishonesty. It seems that in your environment, estimates are being used by management to hold the developers accountable for predictability. This approach is inherently flawed because:

1. Developers, even experienced ones, generally suck at predicting how much time it will take to complete a task, especially when it comes to a task they don't do very often, or has no similarity with anything they have done before, or have not done before at all.

2. As I said with different words before, developers are not psychics nor can they foretell the future.

An estimate that eventually proves to be very close to reality is a well-informed guess at best. That can only be determined after the fact, when reality plays out. Experience and knowledge is what turns a guess into an "informed guess." Any appearance of "accuracy" when it comes to an estimate can be attributed to either a vast amount of experience and knowledge about the task (thus making the "accurate" estimate a very well-informed guess) or if otherwise, to pure coincidence and luck.

There is a quote from a book I've been reading recently, "Thinking Fast and Slow" by Daniel Kahneman, that goes like this:

Herbert Simon wrote:The situation has provided a cue; this cue has given the expert access to information stored in memory, and the information provides the answer. Intuition is nothing more and nothing less than recognition.

On the other hand, your question about developers padding their estimates so that they can "take it easy" hints at dishonesty and non-transparency on the part of developers and the need to "validate" the estimate hints at distrust that management has of the developers, because of their dishonesty and non-transparency.

When used honestly and with integrity, estimates can help you anticipate the likelihood of having to change your future plans. There should be a "neither bad nor good, it just is" attitude towards discovering large differences between estimates and the eventual reality. This is how estimates can be used for good because then you can focus on figuring out how you are going to deal with change rather than trying to find out who to point the finger at and blame for causing you to deal with change.

When an organization doesn't have ways of dealing with unanticipated changes to their plans or if it is unwilling to assume the cost of consequences associated with changing plans, that's when dishonesty and non-transparency starts to creep into the system. Then people start to play all kinds of games to try to please others to whom they are "accountable."

What they all really should be doing is to work collaboratively to understand the risks and consequences associated with anticipated and unanticipated changes, then come up with ways to mitigate the risks and negative consequences of changing plans and bring down costs of dealing with change to a level that is acceptable or tolerable. That is what "embracing change" is all about. When you don't embrace change that way, change will embrace you and squeeze you to death.

[Satyaprakash Joshii]

This is a good start:

Yes,Thank You. I have gained self confidence after discussion in this thread.

The doubts you described all hint at an atmosphere of distrust and dishonesty

Do you have a lazy developer on your team? That sounds like a problem for management to deal with directly.

No. Actually , some of the questions now are not because of my situation but out of my curiosity regarding agile based on the discussion in this thread.

It is not so but I got curious to know the reason for this regarding agile based on the discussion in this thread.  I want to know that out of the below 2 situations the company will benefit more with situation 2 than situation 1. Then why is it said that 2 should happen.



Situation 1: Developers give the estimate and complete 5 tasks in say 40 hours.

Situation 2: Developers are given deadline to finish 10 tasks in 40 hours. It will not happen but because of the pressure developers will be on the toes and will finish 6 or 7 tasks in 40 hours which is more than 5.

Will the company not benefit more in Situation 2?

Sometimes the reason is that the task took longer than expected. (Or a higher priority task took longer than expected which didn't leave enough time for this one.)

Yes, such kinds of reasons will be written in comments for "Spring Goal not met" but no developer is ever going to write "because I did mistake and because of which it took lot of time". Developer are always going to write reasons other then where mistake is his.So you would not always get actual reasons in comments.

[Junilu Lacar]

Satyaprakash Joshii wrote:
Situation 2: Developers are given deadline to finish 10 tasks in 40 hours. It will not happen but because of the pressure developers will be on the toes and will finish 6 or 7 tasks in 40 hours which is more than 5.

Will the company not benefit more in Situation 2?

Are your developers robots whose performance does not suffer under pressure? The truth is, most people make more mistakes when they're working under pressure, especially when it comes to work that is more cognitive rather than it is mechanical. I assume by "finishing tasks" you mean programming tasks, not manual labor. Programming IS NOT about typing. Programming is about thinking.  If your programmers "finished" 6 or 7 task because they were under pressure to deliver, do you really believe it's because they think faster under pressure? Frankly, I find that an absurd idea.

Again, it goes back to honesty and integrity. Did you really finish the 6 or 7 tasks in the same time? Or did you cut corners and skip testing? Did you copy-paste code for expediency, thus creating more potential problems that will have to be addressed in the future?

Also, it seems like you're making the assumption that all 6 or 7 tasks have the same complexity and scope as the 4 tasks. Really? When have you ever encountered such consistency in tasks? And if the tasks are all the same, then why not automate their execution so that a human doesn't have to do it?

The scenarios you propose have many invalid assumptions that are very easy to refute.

[Junilu Lacar]

A company gets more value from programmers who are diligent, thoughtful, and detail-oriented, not programmers who rush through their work and create messes that either they or other people will have to clean up afterwards.  Diligence, thought, and attention to details takes time and effort. You can't rush good. You have to just let it happen at its own pace.

[Junilu Lacar]

Satyaprakash Joshii wrote:Yes, such kinds of reasons will be written in comments for "Spring Goal not met" but no developer is ever going to write "because I did mistake and because of which it took lot of time". Developer are always going to write reasons other then where mistake is his.So you would not always get actual reasons in comments.

I'm assuming these comments you're referring to are getting added to some kind of electronic lifecycle management system to track the progress of work, like JIRA or Rally.

So what if the developer doesn't say he/she made some mistakes during the development process? As long as they corrected the mistake what does it matter? Programming is NOT something that you normally get right the first time. We experiment, we get feedback by running tests, we make corrections and adjustments. Sometimes, it takes a while for us to work through problems. So what? I assume you hired people who are reasonably competent. Even the most competent people will make mistakes.

In fact, I purposely make mistakes while I'm writing programs so that I know what NOT to do. This process is called TDD, Test-Driven Development, in which writing any increment of production code always starts by writing an increment of FAILING test code. That makes me certain that there is something wrong with my code. That also means I am allowed to go to the production code and fix it. Then, after I make the failing test pass, I go back and clean up both the increment of test code and the increment of production code.

I am very proud that I develop programs this way because it's not about getting it right the first time. What matters is that you got it right in the end.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:Situation 1: Developers give the estimate and complete 5 tasks in say 40 hours.

Situation 2: Developers are given deadline to finish 10 tasks in 40 hours. It will not happen but because of the pressure developers will be on the toes and will finish 6 or 7 tasks in 40 hours which is more than 5.

Will the company not benefit more in Situation 2?

Not if there are bugs and therefore rework. I was talking to someone today (not on my team) who wasted a couple hours on what could have been a ten minute task because of being pressured/distracted. Definitely not better.

Also, suppose you estimate the 5 tasks in 40 hours and the tasks turn out to take 30 hours. This is great. You have 10 hours to help teammates who estimated too low. Becayse on average someone is likely to need help. And if the whole team had a great sprint, you can learn, clean up tech debt or even start a new feature.

My team actually "cheats" a little with our Scrum implementation. We plan about 10% of our tasks to be "below the line." These are tasks we plan but don't commit to doing. They get done if the committed to tasks got done faster than expected. Or if we were blocked on an external force that prevented a committed to task. (I'm on a DevOps team. If we have a dependency with an external team who suddenly doesn't have time for us, that can derail some types of tasks.) Either way, we find it helpful to have something "waiting in the wings." It was still prioritized by the product owner. Just at a lower priority for the committed to work and with an understanding that there is a good chance it won't get done.

I use the term "cheats" because this isn't part of Scrum. It's something that evolved over time and lets us accomplish more story points of work on average without having to do replanning when "there is suddenly" extra time. But notice how we aren't being pressured to do this extra work.

Satyaprakash Joshii wrote:Yes, such kinds of reasons will be written in comments for "Spring Goal not met" but no developer is ever going to write "because I did mistake and because of which it took lot of time". Developer are always going to write reasons other then where mistake is his.So you would not always get actual reasons in comments.

The two most senior people on my team do (myself included). In fact, we intentionally put an emphasis on our mistakes when talking with the rest of the team. This models that mistakes are normal, natural and a part of development. And that there aren't negative consequences when talking about them. On your team, I agree nobody is going to write that. Different team culture and trust with management.