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 a small group of 3 developers working on a project, using Scrum.
We are using 6 hrs/day/developer for capacity planning. My question is - if we are using 2 week Sprints and spend most of the day (5-6 hours) doing Sprint Planning, should we consider this time as part of the iteration (i.e that is why we are using 6 hr/day to account for things like this).
To me, this falls outside capacity planning as the 6 hr/day/dev is only to account for productive time doing normal things that a developer does on a daily basis....
You should do capacity planning in terms of stories. How many stories can you do this week? In this way you don't need to account for planning because it's not a story.
If your stories have sizes so different that you can't really plan sensibly without accounting for it:
estimate the stories in arbitrary "points" (basically size them one against the other) (good)
or
break your stories so they all become equally small (better)
In either case, you don't need to account for planning anywhere.
Sprint planning time should not be accounted in sprint iteration. But sprint planning should be completed in 2-3 hrs, not be done the whole day. Since you say your team is small consisting of 3 people, then ideally sprint planning should be completed within this time. So rest of the day is still available for sprint tasks.
I have tried a few different things, but here are the ideals that have worked best for me:
Think of dev work as 'closed door' costs: how long would it take if she was never distracted by emails, meetings, phone calls, lunch, beer runs, etc.
Identify, for your team, the ratio between 'closed door' costs and real life. Do your planning in 'closed door' (easier for devs to estimate) and use history to identify the ratio. This also allows you to try things out to lower the ratio (free soda/lunch delivery, email filters between 10am and 4pm, etc.)
Consider sprints as having a full day for planning, stabilization, and review. So for a two week sprint, use Day 1 for planning, Day 9 for stabilization, and Day 10 for review/retrospective.
So if you have 5 developers working 8 hours a day for a two week sprint, and you figure out that your closed door/open door ratio is 1.5, you have 5.33 closed hours * 5 devs * 7 days = 186.6 hours of work you can plan for.
If you have a strong SCRUM master (or other process leader) and push your team to have a complete definition of 'Done' (i.e. documented, tested, buddy built, and integration tested), you won't need a stabilization day, but it takes some effort to get there.
The benefit of this blended process is that you can use the open/closed ratios to understand each developers work habits (some are great estimators and have a ratio of 1, some people are pessimistic about everything and might have a ratio under 1).
No, you should not consider the sprint planning as part of the sprint iteration.
The hours the team spends during sprint planning is not considered when calculating the development team's capacity, as the time spent in this meeting does not contribute to the development of stories.
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
I understand that on the first part of your sprint planning, you would size the stories for example using story points and poker cards and then you estimate how many stories you can tackle on the next sprint. So let´s say you agree on working on 3 stories with a total combined of 18 story points.
Then you go ahead with the second part of the sprint planning and you start breaking those stories down into tasks. These tasks are now estimated using actual hours.
I have two questions:
1) How do you estimate the tasks in hours? do you use again poker estimating but with number of hours this time? how does the team agree on the number of hours for each task.
2) Once you estimate all tasks for the 3 stories you agreed for the sprint, you find out that the number of total hours combined for all tasks of all 3 stories is 90 hours for example. If your actual team capacity in hours is 75, how do you adjust your initial commitment of delivering 3 stories now that you realize that you don´t actually have the time to do it? Do you go back to your Product Owner (if he´s not there anymore) and tell them that you will be delivering 2 stories instead or how do you go about this?
Thanks a lot in advance for your help!
The tasks are not really estimated in hours but ideal hours. It's really hard to predict how many ideal hours will be available in a week, and it's generally not a good idea at all to infer the capacity on a sprint based on hour estimates. See for example this Scrum Alliance blog article
Story points and task hour comparison can be thought of as the comparison of the weight and height of an elephant. In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.
Normally, tasks are tackled by a single team member (or a pair), and thus they are estimated by them, and not by the whole team.
Furthermore, tasks are re-estimated daily: the number we look for is the number of ideal hours left to complete the task and not the total amount. So, it is a number that can go up or down, or remain constant.
Also, tasks can be added or removed during the sprint. It's actually pretty common to discover that initial plans change. It doesn't matter, as long as the total number of hours planned represents the best current estimate of what's left to do -- it's needed for burndown charts.
In conclusion, don't mind the hours. Use them to monitor progress during the sprint but not to determine capacity. This is what points are for and the two parameters are not interchangeable as it would seem.
In my experience, breaking into and estimating tasks is very useful and often underated. The idea is that the team become more and more accurate as time goes on through their sprints and they inspect and adapt. I have observed teams getting to the point where they end up completing everything in the sprint except for unforseen blockers (eg. Server down time). The idea is that the team calculate their capacity in (hours) and then calculate the amount of tasks they need to complete ( in hours). They can use this as a guide to make a commitment. There is a more detailed explanation here: http://www.pashunconsulting.co.uk/team_commitment_blog.html
You can also use story points to make a commitment but the general principle is that Story points are better for long term estimation (ie. for estimating when the project will deliver). Agile Estimating and Planning is a good book for this kind of stuff, as is the Scrum Mega Pack.
I guess an issue come from the assumption that you are able to deliver 18 points within a sprint. What looks not right when you do an estimation in hours later. So, commit to fewer number of story points initially and after several sprints you would be able to know your actual velocity in story points per sprint.
While breaking stories into tasks is helpful, it is not very useful to estimate those tasks.
The reason is that you will spend a lot of time doing these micro estimates and they will generally be inaccurate.
Besides, adding concrete hourly estimates forces work to fit in those estimates.
If you underestimated you might procrastinate, if you overestimated you might skip on reviews, unit tests or other quality practices just to fit the timeline.
So in general I like to stay with one estimate level -> the one that gives the velocity.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have just moved to a company where the production team is 15 strong, and consists of a mixture of back end and front end developers, testers & creatives. The team are working on multiple projects at the same time. Its agency work, so projects are fairly small, a CMS corporate website, a basic e-commerce site, that sort of thing.
At the moment the Project Managers make weekly resource requests for greater than 6 hours to be added to a long term production schedule, which runs as far as 6 weeks ahead. This is then transferred on a Friday into a short term schedule for the coming week. Added to this are requests of less than 6 hrs. If we are short in resource, we get in freelancers which are costly.
There are a lot of changes that happen to this weekly plan. Work get's pulled on the day it happens due to a dependency not being met, or another priority project coming in. The client doesn't get creative to us in time etc.
Partly there is a lot of bad planning going on, so I can start there. Although, I've been researching into what the ideal pipeline/work schedule should look like, and can't find anything for agile that applies to this structure.
Does anyone know if there are agile theories for agency type work?
In general, SCRUM will work for this sort of work load. The only difference is that you may have to modify it a little bit so that you can group tasks related to a particular project into the same sprints so that you are not constantly switching projects for every task.
On the up-side, it seems like you are already doing weekly sprints, so it shouldn't be a hard transition.
Lastly, if it seems like there is too much churn going on for a 1-week sprint cycle (you mentioned the "fire fight" mentality causing issues currently), you might want to try 1/2 week sprints.
Kanban would be an easy fit. It is a Lean-Agile approach that allows steady flow and recurring stuff (e.g., recurring planning, recurring demos and releases, recurring retrospectives, whatever, as desired), but because it's flow-based and just-in-time, it's PERFECT for situations where priority changes daily or there's lots of firefighting.
To start Kanban, you could keep your current process and workflow, begin a few practices (visualize work by workflow state on a big poster/board or electronic tool, put work-in-progress limits on each workflow state, and have regular retrospective meetings to continuously improve the process.
Lean and Kanban talk a lot about queuing theory and theory of constraints. The idea to planning is to only plan as much as you need. In a perfect world you would only ever need to know the next-highest priority item, because if you do too much batch planning (or batch anything, hence the WIP limits) that could be considered inventory, which is waste.
Kanban allows prioritizing by things such as urgent customer need, deadline (e.g., penalty if date is missed), normal work, etc., using classes of service and service-level agreements.
For example, issues that are blocking a customer are #1 priority, and might even cause us to exceed WIP limits and switch from in-progress work to satisfy. Such work will be done within 3 days 90% of the time. (Such agreements should be derived from real data, which you'll start to accumulate if you record item state each day, e.g., in a cumulative flow diagram.)
Along with classes of service and SLA's, you can also stipulate that 20% of the team's time should be spent on these urgent ("expedited") issues, 60% on normal work (feature development, for example), and perhaps 20% on continuous improvement, hygiene, technical stories, etc.
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
Is there a difference between Sprint and an Iteration or one can have Iterations within a Sprint or Sprint is just the terminology used instead of Iteration in Scrum? It will be helpful if someone can throw some light on this.
Suppose there are 4 sprints and you have decided the first sprint will go up to 10 days is it required that other 3 sprints should have the same length of the 1st decided sprint's length??.
All sprints are iterations but not all iterations are sprints. Iteration is a common term in iterative and incremental development (IID). Scrum is one specialized flavor of IID so it makes sense to specialize the terminology as well. It also helps brand the methodology different from other IID methodologies :)
As to the sprint length: anything goes as long as the sprint is timeboxed i.e. it is finished on the planned date and not "when it's ready". (Or alternatively, in rare occasions, the sprint is terminated prematurely to start a new sprint in case some essential boundary conditions are changed.)
It does help to have the sprints of similar durations. There's less to remember about the sprint schedule and your planning gets more accurate. I like to keep mine at 2 calendar weeks, which will resolve into 8..10 business days outside holiday seasons.
Sprint == Iteration.
The lengths can vary, but it's a bad planning precedent to let them vary too much.
Keep them consistent in duration and you will get better at planning and delivering. Everything will be measured by how many 10-day sprints it takes to finish a series of use cases.
Keep them consistent in length and you can plan your deliveries, end-user testing, etc., with more accuracy.
The point is to release on time at a consistent pace. A regular schedule makes management slightly simpler and more predictable.
The important thing about a sprint is that: within a sprint the functionality that is to be delivered is fixed.
A sprint is normally an iteration. But you can for example have a 4 week sprint, but have 4 one week "internal" iterations within that sprint.
There is a lot of discussion about the length of sprints. I think that if you do it according to the book they should all be the same length.
We have found that a short first sprint to get the development environment up and running, followed by longer basic functionality sprints, then short sprints towards the end of the project, has worked for us.
"___ is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"
No this is not the definition of scrum, it is the wikipedia excerpt on the definition of burnout.
Dont do too many short 10 days sprints. You will burnout your team eventually. Use short sprints where you really need them, and don't do too many in a row. Think long-term. A distance runner always paces themselves for the full race and does sprints in short distances only where it matters.
If you burnout your team you can toss out all them fancy scrum charts, they won't do a thing for your team's plummeting productivity.
Iteration is synonymous with sprint, sprint is just the Scrum terminology.
On the question about sprint length, the only caution I would note is that in Scrum you are using the past sprints to gain a level of predictability on your teams ability to deliver on their commitments for the sprint. They do this by developing a velocity over a number of sprints. A change in the team members or the length of the sprint are factors that will affect the velocity for a sprint, over past sprints.
Just as background, velocity is the sum of estimation points assigned to the backlog items, or stories, that were completely finished during that sprint. Most Agile proponents (Mike Cohn, Ken Schwaber and Jeff Sutherland for instance), recommend that teams use "the recent weather" to base their future estimations on how much they think they can commit to in a sprint. This means using the average from the last few sprints as the basis for an estimate in the upcoming sprint planning session.
Once again, varying the sprint length reduces your teams ability to provide that velocity statistic which the team uses for sprint planning, and the product owner uses for release planning (i.e. predicting when the project will end or what will be in the project at the end).
I recommend Mike Cohn's book on Agile Estimating and Planning to provide an overview of the way sprints, estimation and planning all can fit together.
Where I work we have 2 Sprints to an Iteration. The Iteration demo is before the business stakeholders that don't want to meet after every Sprint, but that is our interpretation of the terminology. Some places may have the terms having equally meaning, I'm just pointing out that where I work they aren't the same thing.
No, sprints can have varying lengths. Where I work we had a half a Sprint to align our Sprints with the Iterations that others in the project from another department were using.
Sprint is just the term for an iteration.
You can change the Sprint length to be anything you want, but likely you'll want to try to find an amount of time that "works well" (which may mean any number of things for your team) and end up sticking with it over time.
According to my experience
Sprint is a kind of Iteration and one can have many Iterations within a
single Sprint (e.g. one shall startover or iterate a task if it's
failed and still having extra estimated time) or across many Sprints
(such as performing ongoing tasks).
Normally, the duration for a Sprint can be one or two weeks, It
depends on the time required and the priority of tasks (which could
be defined by Product Owner or Scrum Master or the team) from the Product
Backlog.
ref: https://en.wikipedia.org/wiki/Scrum_(software_development)
Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm currently working on a productivity tool for Scrum teams and would like to know what is the average number of stories you see in a product backlogs at any particular time.
Just to clarify the number should not include completed stories or stories which 'might' be broken into multiple stories in the future. Also I'm interested in what people 'are' doing rather than what they 'should' be doing.
Unfortunately I don't get out and about enough to other peoples labs so only really have experience with what's normal for us.
I'm guessing there are quite a few consultants on this site who maybe get to see far more team rooms than I do.
Now I know this is a "how long is a piece of string" type question and there will be some people with two and some with two thousand, but I'm just looking for a yard stick.
For the teams in our company is is usually less than twenty.
Regards,
Chris
"Just to clarify the number should not include completed stories"
Got that.
"or stories which 'might' be broken into multiple stories in the future."
What? That's half our backlog.
There's always 5 ± 2 stories in the official backlog, because that's about all our product owner's brain can handle. When we finish a few, some more get tacked on the end as "well, we might want to look at this, too."
As architect, I can foresee an additional 5 ± 2 stories of a more administrative, technical nature.
Those are the top 9 stories in our backlog.
Plus there are always the vaguely defined stories "which 'might' be broken into multiple stories in the future." Interestingly, these appear to number 5 ± 2.
There are 3 or 4 of these, depending on your "'might' be broken into multiple stories" rule.
Beyond that, of course, additional people would like to throw stories at us. For example, our sales guy has 5 ± 2 stories that are part of a sales demo he'd like to see. It isn't core functionality, and it's vague and it "'might' be broken into multiple stories", so I guess it doesn't count.
I think it counts, BTW. Every story must be tracked. The change and mutate and get broken down, but it's impossible to discern "real" from "might get broken down". That's the point of prioritizing the stories -- vague or large or ill-defined notions can be tracked as backlog until they get so low priority that other projects are more important than the outstanding backlog.
The correct answer is (5 ± 2 stories) × number of stakeholders.
If you don't consider epics as you mentioned, I would say twice as much stories as you complete during one sprint. I think that will varie between 20-30 according to the size of the stories and the size of the team.
Currently we have 7 stories that aren't part of a sprint in the backlog. But we're currently building the backlog, so not much of a reference.
just had a quick look at our issue tracker: we complete about 15-20 stories per sprint and have a rough plan/assignment for the next 3 sprints. the unassigned backlog portion tends to be between 10-20. our complete backlog thus contains roughly between 50 and 100 stories. i guess this will vary quite a bit, depending on how close we are to a release (currently we have about 4 sprints to go; a usual release cycle is about 15 sprints long) -- just to give you a rough estimate on the "length of the piece of string" in our team :)
It really depends on the project tbh.
For the uncommited backlog; on the lowest projects it's about 5-10, and the highest it's about 25-30.
The sprint Backlogs are more consistent and generally have about 7 backlog items per spring (2 week sprints).
A good rule of thumb is to spend 5% of the team's time maintaining the product backlog - having 1 to 2 sprints worth of stories fully groomed. For my teams this usually corresponds to around 15 to 25 stories.
It's surprising how consistent these numbers actually are between posters.
For 2 week sprints: 3 - 7 stories, depending on their weight. More stories if its new functionality, less stories when building or changing old/existing functionality.
Backlog'ed stories per project: 25 - 40 total?
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
Does anybody use Scrum & Sprint for Infrastructure.
I'm struggling with the concept of a Sprint that never finishes i.e. a Network enhancement project.
Also any suggestions on how Item time can be built up to a Product Backlog, so that I can sanity check that resources are not overcommited on the sprint.
I would suggest that you might start by refreshing your memory about the whole concept of Scrum (http://en.wikipedia.org/wiki/Scrum might be a good place to start).
For example I don't believe that there should be such thing as a 'never finishing sprint'. If you have some very long and/or recurring task just break it into more specific ones. Network enhancement is very generic - break it down to:
a spike to research new network equipment
a spike to review your cables layout
a task to draw the equipment physical locations and wires diagram
Estimate these and put them into your Backlog.
etc.
Then plan short (1-2) week sprints or iterations. Assign a specific goal to each of them. Add some of your tasks from the backlog to the iteration. Complete it.
Review the results, adjust the process, repeat.
Scrum is a project management method, it is not specifically aimed at software development ; so it can be used for network enhancement project.
You said you're struggling with "sprint that never finishes", that is not Scrum. Sprint are timeboxed, they finish on time, period.
Now, if the team overcommitted for the sprint, or if some tasks were underestimated, and there are backlog items that are not "done done", they are removed from the outcome of the sprint, and may be continued in the next sprint.
There are several things you can do to prevent overcommitement :
backlog items shall be small ; small items are easier to estimate that large items. Actually, they should have INVEST characteristics. EDIT: the backlog items should be sized so that the Team can complete between 5 and 10 in one Sprint, on average.
after the first sprint, you now how
much the team can put in a sprint
(provided comparable ressources)
do not allocate people 100% on the sprint, start with 80% as a rule of thumb
define what "done" means
re-estimate your backlog items based on what your learnt
If the network enhancement project never finishes, I assume it is because new needs are identified. Add them in your backlog, prioritize them, estimate them, they will eventually be scheduled in a sprint.
You might look into Kanban. You still have a backlog, but instead of timeboxing it imposes WIP limits throughout a process flow. I still recommend using the Scrum communication plan w/ standups and regular retrospectives and demos if appropriate. Planning meetings are a little different in that you are not actually committing to any work, but you can still use stories and story points (WIP limits can be on story points). If you are meeting every two week, I would make sure you have 2.5 or 3 week of work queued up (although an advantage of Kanban is you can always add the next big thing to the top of the queue without having to wait until the next sprint).
Also I like the fact that you can have swimlanes representing their various clients as infrastructure is often working on end user support tickets and supporting multiple projects in addition to their own day to day work.
In waterfall you would build and release all at once. In Scrum you build and release periodically, in short sprints. With Kanban, you just keep the water flowing.
Google Infra-gile for more.
A Sprint that never finishes is not a Sprint...it's a career. JK. Make sure you have clearly defined sub-goals if a major goal is not reachable and/or constantly shifting. Estimate man hours on each task and break it down into sub-tasks if those hours get to be more than half a day or so (very loose rule). Track time (doesn't have to be precise--can be logged at the stand up meeting or through your project management system or ticketing system) and compare to tasks. You will find some tasks that are similar in function and time to complete. Use those as prototypes for the next sprint and keep enhancing it until you are getting more and more on the mark.
Once you have a pretty good handle on that, revisit your backlog, assign estimated time and start defining solid goals (which are made up of discrete, well defined sub tasks), stretch goals, and distant goals for your sprint. Solid goals should be well within your team's reach (no more than 60% of your estimated goals you can accomplish and usually less), stretch goals should be from that point to what you estimate you can accomplish (at 100% estimated efficiency) and distant goals you should have on your radar in case you have a fantastic bit of luck that sprint. Everyday, review and chart your burn down at the stand up, and re-eveluate your goals for that sprint. If there are wild changes in your estimates, note why, and if they are systematic, revisit your tasks and estimated time and readjust so your next estimate will be better. This is a whole lot of work at first and it takes a remarkable amount of discipline but the payoffs after a few months are huge. Just keep grounded in strict reality. Good luck!