Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
My team estimate tasks with hours, which is related to the TFS SCRUM Template nomenclature, however I've heard recently that tasks should be estimated in some abstration unit and using of hours is evil, what is the recommended way?
You can estimate in hours provided your team velocity is also based on hours since that's how you decide how many backlog items are likely to be delivered in a sprint.
But it's not necessary to use hours and it can sometimes give a false sense of exactness.
If you use an abstract unit for both estimating and velocity, you (or, more correctly, stakeholders and others who don't understand Agile) won't be confused into thinking that hours is an exact measure.
The confusion will stem from the fact that velocity is work-units-per-sprint and "hours-per-sprint" will be unchanging if your sprints are always a fixed size (say, four weeks for example, which will always be expected to be four weeks by forty hours by some number of workers).
However, your velocity is actually expected to change over time as the team becomes more adept, or experienced people get replaced with those with less experience, or half the team takes a month off on holidays.
That's why the whole concept of story points exists. They provide such an abstract measure so as to avoid this confusion. You simply estimate your backlog items in story points and keep a record of how many points the team delivers each sprint (the velocity).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We have a project which is deploying thorough Scrum. In Scrum you will update your estimates during the sprint and set them with the remaining time. We use youtrack for tracking the project and particularly its Agile Board. We used to update estimation -as I told- during the sprint with remaining time.
But I found that decreasing the estimations (when work goes on and estimate of remaining time should be decreased) wouldn't be reflected in burndown chart. It just draw that chart by sum of Whole sprint tasks estimation and sum of fixed sprint task estimations. A change in estimation will just scale whole chart, not be reflected as works goes on.
How should we change our estimates to watch it on burndown chart?
In 5.0.* version youtrack's burndown chart doesn't relies on 'old' estimation values. Ideal burndown and issue estimations values are taken from current values. In 5.1 it will have such ability (http://youtrack.jetbrains.com/issue/JT-22390)
If I'm understanding the question correctly, you need two fields. Original Estimate and Remaining Work. This will allow you to keep track of the % complete of the original size.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are following Agile development methodology. As a SCRUM master, I am maintaining the Sprint BackLog. I want to know what is the best practice to accommodate any increase in effort for a particular task in the middle of a project.
For example, I am doing ABC task and in the starting of the sprint I have estimated that it requires 10 hrs to complete it, but on the second day I realized that it requires 20 hrs, so how will i update the Sprint Backlog.
You change the remaining work to 20 hours. Scrum is concerned with the actual work remaining, not whether the original estimate was right. That's important, but it's not explicitly part of Scrum.
If this threatens your ability to deliver on your commitment, then you need to discuss solutions with your team and possibly also the product owner. Perhaps:
A teammate might have a simpler solution.
Other tasks were overestimated and you can still deliver everything.
The product owner might decide it's not worth the effort.
Sprint planning was rushed and the sprint should be declared a failure and restarted.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Does the product owner actually vote on the size of the story in Scrum or is it just Dev/QA?
I was wondering, because it does not really seem like having the product owner vote is productive.
In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Could somebody please explain this to me. It seems to me that the number of story points actually delivered at the 50th percentile would be more valuable than a theoretical number that is far more likely to get affected by outliers, especially in the early days of an organization adopting scrum.
Actually nobody says that you can't use median. Scrum just shows way to drive the proces but you can bend it (improve it) to your needs and understanding.
If you want a statistically significant method to calculate velocity, you might try using the average and standard deviation. This way, you will be able to predict with whichever degree of certainty you are required what your velocity is.
If you wish, you can limit the data to the last few sprints, if you notice a change in the trend, and can explain it as valid.
This goes towards the Agile values of communication and courage (for the stakeholders to accept the uncertainty of the prediction).
e.g.
Team: Based on the last 5 sprints, we are 90% certain that we will be able to deliver at least 30 SP in the next sprint.
scrum doens't use average or median, it's a particular team that will choose one over the other depending upon the sophistication they want..
I will suggest if outliers are the problem then choose something like average of last 7 to 9 iterations... so once you are in lets say 15th iteration you won't be having any effect of early 'bad' iterations... .
I've found measures such as average sprint velocity (or median in your case) to be a very poor way to determine what the next sprint velocity may be. The main problem is that the formula is driving the decision making and this allows a team and SM to substitute that for real thinking.
The best way to compute next-sprint velocity that I've found (using Scrum for almost 5 years) is the following:
In the first sprint or two, it's just an educated guess. We make a guess then drop back from that a bit to ensure we don't overshoot.
If the team has picked up, say 5 extra pts in the prior sprint, increase the velocity by no more than 5 points. If the team didn't pick up any new points, keep the velocity where it is unless they struggled. If they struggled, back off a bit, say, 10%.
If the sprint failed, regroup and figure out whether it was because the team picked too much work. If so, work out what stories were actually done 100% - this total of points is your new velocity for the next sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What approach did you take to describe the benefits of SCRUM to clients / business units who do not have a technical background? Please list any analogies you thought were useful. Finally, how did you address the concerns that the Waterfall camp had?
I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.
Using a incremental process significantly reduces the risk of wasting money on something that's not gonna be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles. The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?
Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.
You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction.
An additional point is protection of investment - with traditional approaches, a system typically "ages" with time, its value decreases, and maintenance costs rise until it's no longer feasable to maintain it. With an Agile approach applied well, the code should be maintainable and extensible indefinitely.
Here is a good, short video on all three points: http://www.youtube.com/watch?v=OWvSnYjqOTQ
I would mention the benefits of focus. Because the guiding principle of sprints is functional focus and shipability, all details (e.g. ergonomics) need to be taken care of, whose fixing would otherwise be postponed under pressure in more global approaches. You don't have it all but what you have is solid. Non technical people appreciate that because it reduces risk from their point of view: it injects honesty and trust, together with interactivity, in the dialog with clients.