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
I've been using Scrum for some time, but I still do not have a clear understanding of how to handle the case when all team members have different working speed. For example, given an abstract task an employee A will solve it in 5 days while employee B will need about 10 or even 15 days. My team consists of very different (in expertise) people, so they literally work by different speeds.
These are the main misunderstandings:
How to measure user stories in ideal man-days because they are very different inside the team? (There are often arguments since some people have experience in the area and some don't so they would need to spend some time reading the docs and doing small steps)
Why to calculate team velocity if I would need to calculate each individual's velocity then to be able to give right amount of work to everybody? (Another reason to calculate each individual's velocity is that there is a big difference when a senior guy goes to vacation and a junior)
Velocity is merely here so that the team may take a rough guess at the amount of work it can commit to for the next sprint.
Story points only have a meaning relatively to another story, not as an absolute value, because their sole purpose is to draw a broad stroke parallel between stories the team as a whole has completed until now, and stories it will have to deal with in the future.
If a senior developer goes on vacation, just adjust planned velocity for the next sprint accordingly. Don't take it as a pretext to introduce complex estimates, they will only give you a false sense of security and get you deep in a fractal estimation mire, distracting you from your primary goal which is to deliver value.
You don't need to relate story points to man hours. You don't need to calculate team member-specific estimates. You don't need to pre-assign stories to people.
Scrum has no concept of individual performance. It's always about the team. You'll always have individuals that perform to varying degrees and if you try and plan for that, it'll drive you slowly insane.
My strong advice is to ignore the performance of the individuals and concentrate on the velocity of the team.
My 2 cents: All my projects have included Scrums. The best way to handle such case is to let the team members choose their stories and assign them points. 3 point is for story that can be done quickly, perhaps 4 hours or less, 8 point is story that would require a person to complete the story within 1 working day(8 hrs), and 13 point(3 days or less) is the story that will require the person to do some research on implementation, implementing and testing it
There should be lead team developer who understands the working velocity of other team members and can assign the stories to other members based on their ability.
If you think the story will require more than 3 days to be completed, then it should be further divided into mini stories that will require less time to do so.
Related
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 1 year ago.
Improve this question
I am new to scrum , I would be happy if you tell me as a scrum master what should I do in a backlog grooming session and when sprint planning happens exactly and how we estimate the amount of time that we need for each item in the backlog and what planning poker estimates exactly.
It's definitely worth looking at the Scrum Guide for some guidance, though that certainly leaves a lot of room for interpretation. For sprint planning, there are three parts, noted here: https://scrumguides.org/scrum-guide.html#sprint-planning
You're going to want to establish a preliminary sprint goal (the guide notes that it doesn't have to be finalized until the end of planning), then identify which backlog items need to come in to meet that sprint goal, and finally, put together a preliminary plan on how the work will be done. Of course, this is all collaborative. Generally speaking, the PO focuses on the most important work being done first to deliver the most value and the developers focus on what's a reasonable workload and how doing different tasks together may be more effective than others.
Refinement is purposefully vague. It's whatever conversation need to happen to make upcoming Sprint Plannings successful.
Planning poker is a rather broad topic - it is simply a technique for relative estimation. These sizes represent the overall size of an item relative to others. This is not a direct translation to time. Rather, there is a correlation when discussing similar work with a similar team. A great analogy from Mike Cohn is with distance running. A 10k is one size bigger than a 5k, but it doesn't tell us how long a given runner would take and you can't assume that any given runner will take twice as long to run a 10k as they do to run a 5k (or any other clear ratio). However, once someone runs a number of these, you can start making rough time estimates about how long it will take that runner to run similar courses.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. Scrum master helps the Scrum Team understand the need for clear and concise Product Backlog items.
It should be done before Sprint planning and the team should do it frequent basis. In backlog refinement, the Scrum team discusses/refine stories. If possible then assign story points as well(Size estimation, could be t-shirt sizing or story pointing). Story points are provided by taking some small stories as a base story and by comparison we can give story points. Or we can give story points based on work that needs to be done and the efforts it will require. Before starting with the story pointing team should agree on some mutual measuring unit(Can take a story as a base, Required Efforts, many more ways). Usually, it's kind of a rough estimation. It's good if you have some field in your tool to make stories as ready/draft/purposed...
The scrum master needs to ensure this session should happen and facilitate the same.
In Planning, Majorly team decides what can be achieved in a sprint. Value of the sprint and plan on how we will be achieving the targets. The team sits together and takeup stories from the refined backlog. Before starting taking up stories team should calculate team capacity by capacity planning. Usually, the team should take up stories that are in a ready state(Means already discussed). Scrum Master facilitate this event. Usually, planning is done by the scrum development team.
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
We have up to several team members that does not work 100% on our team. You might argue that this is a bad idea in the first place, but lets assume we can't do anything about it. I have had a discussion with one of the other team members, and my argument is that the burndown chart is "lying" to us. Let me give you an example.
Lets say we have a sprint, lasting 2 weeks.
We have 6 members, where 2 of them are only working 50%.
If both of the part time members work 100% the first week, and 0% the second week, my argument is that after 1 week, the burndown will look alot better than the reality is. Scrum says that this is the time to add features to the sprint.
Ive seen an alternative way to do this, where you beforehand type in the days you are available, and then have a nonlinear ideal line. My first suggestion was to have placeholders to burn down even if you were not available, but that was shot down pretty quickly.
So I wonder; Should we do anything with the burndownchart? Is the chart even useful? Are there other good practices to overcome this hinderance?
We are currently using Urban Turtle
Regarding the part time developers - obviously, it is not an ideal situation, but there isn't really much of a problem with it. Would Scrum fail if one of your team member wanted to take a day off and would be available for only 32 hours out of 40 in one week? Would Scrum fail if during the week of Christmas nobody would be working? No - on both accounts.
Here's the simplest (and in my opinion best) way to handle your situation: you simply add up the hours that all of the team members will be available for work in that Sprint, e.g. if you have a team of 3, with one member at 100%, and two at 50%, and the sprint is a week, you will add up 40 + 40/2 + 40/2 = 80. That is how many work hours the team has to commit to. It is no different than if you had two full time members.
Regarding the burn down chart - I think that plotting a non-linear "ideal" burn-down is both a waste of effort, as well as misguided. There's a reason it is called ideal. It is not because you must strive to work on that line, but to demonstrate what the burn down would look like if you would (could) work at a constant pace.
Remember the function of that graph - it is there to indicate possible problems in the development. Not every deviation from the ideal is bad. Life isn't ideal, and you are fooling yourself (and harming yourself) if you get worked up over the difference.
In fact, trying to account for every deviation is exactly the predictive method that waterfall famously fails for, and that agile methods try to get away from.
What you may want to do, is to note every major deviation, that you had, understand them and see if there is something you can do about them, and then adapt your process. That is better than trying to model the current state.
So to answer the last question - Are there other good practices to overcome the hindrance - the answer is it is not a hindrance. Overcome it by accepting your reality, and ignoring that which is wasteful.
Your situation is a perfect candidate for using story points over hours. The relative combined effort to complete a story would be more meaningful to your teams ability to deliver value over time, regardless of how much time has been historically spent on similar stories.
There is a very well known anecdote about this situation that turns the situation on its head. Imagine you had a full time team and you knew exactly what hours they could work. Imagine your team had the best scrum practices and you reached a velocity everyone agreed they were happy with. Are they now confined to that velocity forever? Is it conceivable that if you set the same team the goal of delivering the same velocity in less hours and offered the incentive of simply going home early, could it be achieved?
The answer is yes. In fact a real life scenario like this occurred at a major US software house and that team actually got their working week down to 16hrs!! Yes, 16hrs!! They did it by continually fine tuning how they viewed effort. After all, if you take hours to compare stories rather than comparative complexity, how do you factor things like reusable components or cope with unexpected requirement changes from one feature to the next?
Switch to story points, you'll never look back :0)
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
We have just started doing scrum at my company. We are spending a bit of time estimating Effort using planning poker and then when the detailed tasks are worked out a time estimate is put on each task.
The problem we have is that the time estimates are constantly wrong (usually over estimated). Although we can all agree on an effort, getting a team to agree on time for a task is much harder - what takes 1 person an hour might take someone else 3 hours. We end up going somewhere in the middle.
Who should be coming up with the time estimate for a task and when does this happen?
Is this just something we need more practice at, or are we doing it wrong?
The people actually doing the work estimate the cost involved. If you are using raw time as a metric for estimation, Agile methodologies frown on it. Your team should be using an abstraction to estimate cost, such as 'points'. You can start with a rough baseline of 1 hour per point with a minimum of 1 point. Then developers can make raw estimates of how long something should take. Slap them or anyone else on the wrist if they talk in hours or in any other unit of time.
The point is that as development moves along through multiple sprints, project managers can adjust 'point' time estimates provided by the team to match reality -- This can even be done per individual developer. Participants will become better and better at estimation as projects progress. So, since Sprints are an iterative process, time estimates improve with more iterations.
This begs another question: Why are you worried about time? Time is basically cost in the Waterfall model. In Agile, the goal is developing software to VALUE not cost. The reason points are used is that it is an abstract basis of comparison that business owners, project managers and creators (developers) can all view in an abstract light. (Unbiased from different participants' cultural, social or psychological perceptions of time.) Business owners can take a look at available points in a given sprint -- and knowing the points available -- they can elect functionality that is most important. It is always a bit of a tough decision, but again, the goal is to develop toward value and away from time boxing or feature stuffing.
"Who should be coming up with the time estimate for a task and when does this happen?" Depends on how you run your team. Do you let the team members truly self-manage, so tasks are assigned when a person grabs it during the sprint? You may have to keep using the time to complete based on the abilities of an average developer on the team. Do you have a team lead that assigns the tasks to people as they are created during the Sprint Planning meeting? Let the person assigned estimate the time to complete the task.
I agree removing time from the effort estimate is a bit confusing. The big question is: what does it matter that you are overestimating the task time? Is the team sitting around for 4-5 days at the end of a sprint with nothing to do? If so, go to the Product Owner and let her know the team wants to add one or two small items into the Sprint. You don't normally add stuff to an ongoing sprint, but Scrum is a framework to manage work, and as long as the team signs off on adding the new items, there is no need not to let Scrum work for your team....not force your team to work for Scrum.
Also, your questions seems to indicate your team has a greater velocity than what is being planned. If your 2-week sprint (10 work days) has a velocity of 10, but your team is getting finished with everything by day 7, just up your story points on the next sprint to 11 or 12.
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
When and who undertakes the work to sufficiently gather answers so that we can start to write stories for an upcoming sprint. Is this work done continuously and in parallel to existing sprints by the product owner? I guess this then creates tasks for a sprint such as investigate x and y. What if the PO suddenly requires a developer to answer some of the questions by trying stuff out? I understand the idea of spiking and creating r & d tasks. I guess I want to avoid the main dev of a feature being delayed to a following sprint too often.
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.
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
From wikipedia:
During each “sprint”, typically a two
to four week period (with the length
being decided by the team), the team
creates a potentially shippable
product increment (for example,
working and tested software). The set
of features that go into a sprint come
from the product “backlog,” which is a
prioritized set of high level
requirements of work to be done. Which
backlog items go into the sprint is
determined during the sprint planning
meeting. During this meeting, the
Product Owner informs the team of the
items in the product backlog that he
or she wants completed. The team then
determines how much of this they can
commit to complete during the next
sprint. During a sprint, no one is
allowed to change the sprint backlog,
which means that the requirements are
frozen for that sprint. After a sprint
is completed, the team demonstrates
the use of the software.
I was reading this and two questions immediately popped into my head:
1) If a sprint is only a couple of weeks long, decided in a single meeting, how can you accurately plan what can be achieved? High-level tasks can't be estimated accurately in my experience, and can easily double what seems reasonable. As a developer, I hate being pushed into committing what I can deliver in the next month based on a set of customer requirements. This goes against everything I know about generating reliable estimates rather than having to roughly estimate and then double it!
2) Since the requirements are supposed to be locked and a deliverable product be available at the end, what happens when something does take twice as long? What if this feature is only 1/2 done at the end of the sprint?
The wiki article goes on to talk about Sprint planning, where things are broken down into much smaller tasks for estimation (<1 day) but this is after the Sprint features are already planned and the release agreed, isn't it? Kind of like a salesman promising something without consulting the developers.
BTW:
Although the word is not an acronym,
some companies implementing the
process have been known to spell it
with capital letters as SCRUM. This
may be due to one of Ken Schwaber’s
early papers, which capitalized SCRUM
in the title.
You are supposed to use the velocity to plan the next sprint. The velocity neatly handles the fact that your estimates are wrong, but they are consistently wrong. Also note that stories are supposed to be short, I'd say maximum 2-3 days. Stories that are bigger than that should be broken down into smaller stories.
If one story is not completed as planned, then your velocity goes down and you wont be able to take on as much work in the next iteration.
The wiki article goes on to talk about Sprint planning, where things are broken down into much smaller tasks for estimation (<1 day) but this is after the Sprint features are already planned and the release agreed, isn't it?
Wrong, they are done in the same meeting. The sprint stories are not agreed upon until everyone leaves the sprint planning meeting. Whatever questions you need to ask the PO to enable your commitment to the stories; you do before or in the SP meeting
Since the requirements are supposed to be locked and a deliverable product available at the end, what happens when something does take twice as long? What if this feature is only 1/2 done at the end of the sprint
The functional objective of the story is locked, not the implementation details. The details come out in conversation during the sprint. Any details considered to large to be contained in the current sprint scope are put back on the Backlog for later prioritization. Remember, you are building incremental products here. Its like peeling an onion. The story must be satisfied and the code must be working at the end of the sprint. That doesn't mean the whole feature is entirely complete and releasable to a user.
If a sprint is only a couple of weeks, decided in a single meeting, how can you accurately plan what can be achieved? High-level tasks can't be estimated accurately in my experience, and can easily double what seems reasonable. As a developer, I hate being pushed into committing what I can deliver in the next month based on a set of customer requirements, this goes against everything I know about generating reliable estimates rather than having to roughly estimate and then double it!
You are correct here, you can't estimate accurately. Scrum embraces this fact and uses velocity, trending, averaging, and gut-feel to get close. If you don't come to grips with forgetting about accurate hour increment measurements you won't ever feel comfortable with scrum.
In answer to #2, if a feature isn't done at the end of the sprint, you don't deliver it. You may be able to deliver part of it, and if you can do so in a useful fashion, do so. But if you can't deliver it this sprint, remove it, and deliver it in the next sprint.
In answer to #1, there are numerous ways to try to improve the accuracy of your estimates. You might use function-point analysis or just a simple exercise where the entire project team takes the list of tasks separately and comes up with their own estimates for each task, then reviews each task and shares their estimates, and discusses the reasons why (for instance) Bob's estimate for this task is 8h and Tina's is 16h. The team figures out who is right (hopefully) or comes to consensus, and uses that as the estimate.
Over time, you'll come to learn which of your estimates tend to be overly optimistic, and which are overly pessimistic, and thereby improve your ability to estimate your own tasks.
The burn-down chart can really help you here. It is an early warning system for the whole project team, to let you all know when one or more people are falling behind. Then the team can reorganize to help make the sprint commitment if necessary, or cancel the sprint due to unforeseen circumstances, and kick off a new sprint with their improved understanding of the problem space.
Finally, you might consider that statistics are on your side. If you overestimate 10% of the tasks, and underestimate 10% of the tasks, you'll probably be OK.
When we did SCRUM in an earlier project, we first agreed on a rough sprint plan including high-level features (stories), then refined the plan by breaking each of these down to groups of concrete tasks of preferably 1 days max length, estimating each task. After this we often found out that the original plan was overcommitted to some extent (typically because we didn't take into account that developing a story includes unit testing, code review and documentation too), so we adjusted it accordingly. Btw we used "estimation poker": each member chose a card with a number on it (work hours/days) and everyone showed his card to the count of 3. If the numbers differed a lot, we briefly discussed why, and then had a new round until we reached near consensus.
Note also that estimation is very domain and technology dependent. In that project, we understood both fairly well, and we were building a new app from scratch, so our estimations were fairly accurate. In my current project we are working with legacy code, in a domain we don't quite understand yet, so our estimates are often wildly out of range.
As the project rolls on, estimates are gradually getting better (related to the fact that more and more risks and tricky issues are being resolved, and the team's domain expertise grows), so the velocity of the team can actually grow over time.
in answer to #1, I'm not sure I agree with some built in assumptions in the question. In my experience, Agile (including Scrum) is not about time estimates. The whole idea is to move away from that and instead move to a system where you have a known velocity and specific sprint times. For instance, you release every 2 weeks (a good sprint time) with some new code. You see how many story points (not time units, but story points) you get done over a sprint, and then another, and after you've done a few sprints you know your rough velocity (ie, how many story points you can do on average per sprint).
The idea is that the customer gets continuous updates to the application as each sprint is finished and can see constant progress. They know which items are scheduled to come in future sprints but they are aware that if something slips (because of an incorrect difficulty rating, ie. the story point estimation, or an outside problem) it will instead come in the next sprint and everything else will be moved out a little.
So its not about developing the software based on some seemingly arbitrary estimation. Instead, its about planning what functionality or features you want and assigning difficulty (story points) to those features (relative to the other features) and working through them to determine a velocity. Only then can rough estimates be obtained. Once the average velocity is known, we can make some rough guesses about time frames. However, even these should be considered rough approximations because again, its not about time, its about constant feature releases. Clearly, this mindset must exists with EVERYONE on the team, not just the engineers.
Here is a link (wikipedia) that goes into it a bit more.
Anyway, I hope this helps you, good luck!
It's actually quite simple:
You priorize the Tasks and if you see that you don't have enough time then the low-priority tasks simply get dropped or moved into the next sprint.
The Project Owner decides what he wants and sets the priorities and you develop following that order. You should have a useable product at the end of the sprint, not the fully-featured product.