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've been learning Scrum and trying a tool called Acunote for use with it. My question is about two fields I have there, for each task. They're "estimate" and "remaining". What unit should I use for those? Do I use Story Points? What about the remaining? For example I have a task that will take 10 units, let's say. I fill the remaining at the end of day with how many "units" I believe it will take me to complete?
Thanks!
I have a few suggestions for you:
If you are new to scrum; use a whiteboard and don't get bogged down in a particular tool's semantics; it will hamper your learning and adoption.
Break your stories small enough so that you don't have to create and estimate Tasks.
Don't do anything with hours, it is a waste of time to estimate at that level.
Burn down story points.
It is all too easy and common for teams to "think" they are on track because Tasks are being completed and burned down. Then they get to the end of the sprint and find that 5 stories are all 90% done and nothing is completed. If you burn down stories you are actually tracking deliverable business value and not just an arbitrary amount of developer-junk.
As always, my first advice would be to not use a tool when adopting/learning Scrum (I start to be tired to repeat the same thing over and over :). Instead, start with the simplest thing that could possibly work (a spreadsheet for the Product Backlog, a white-board and post-it notes for the Sprint Backlog). The rationale behind this is that you want to learn and master Scrum, not a tool. So don't let a tool tell you how to do Scrum and drive the process.
Then, regarding the question, there are 2 schools of thought: 1. what Scrum says in theory, 2. what some people do in practice.
In theory, Scrum has two levels of estimation: one for work (Tasks) to be completed within the current Sprint and one for more distant Product Backlog Items (PBIs). At the Product Backlog level, items (the "what" is being built) should be estimated in Story/T-Shirt/Unit-less points which have a low degree of precision. This approach avoids "analysis paralysis" pitfalls and accurately reflects the general uncertainty surrounding the work in question. At the Sprint Backlog level, items are beaked down into tasks (the "how" a PBI will be achieved) that are estimated in hours. A separate estimation scheme is appropriate because Tasks describe granular work (usually on the order of a few hours, never more than 16h). In fact, Scrum recommends using "ideal engineering hours" for Task-level estimates.
In practice, some people don't estimate in hours because burning down hours doesn't show "real" progress, which isn't false, and they prefer to burn down Story Points (which really means an item is done or not, it's more binary).
While I understand the "spirit" of the later approach, I don't apply it and stick with the theory. Actually, for the reasons previously mentioned, estimating in hours does make sense to me and I actually find that it gives better "control" of the Scrum empirical process during a Sprint (at the end of each day, you should update the estimated remaining work regardless of the actual time spent and this is easier with hours).
Moreover, I don't like the drawback of having only small stories (which can be seen as waste too) but like when a team identifies clearly what has to be done within a Sprint (this is good for transparency and helps the Product Owner to understand the real amount of work too, especially "quality oriented" tasks).
Finally, I think that you can avoid the pitfalls mentioned by DancesWithBamboo with hours too. Just stay vigilant and:
Always focus on the most important PBIs (and related tasks) first.
Pay a special attention to non-finished tasks, they should keep moving on the white board (if you are using columns to represent steps like for example "todo", "in progress", "to be verified", "done"); a non moving task is a smell.
Don't start a new item before the previous is done.
So, in my opinion, it is possible to use hours and to avoid the "nothing done" at the end of the Sprint syndrome. Just use your brain (Scrum and/or any tool won't replace it, luckily for us).
Having that said, and if you don't throw your tool away, the questions to answer are: what do you want to show on the burndown (points or hours depending on if you breakdown the work into tasks or not, I gave you my point of view) and what field does Acunote use to draw the burndown (i.e. where should I update the estimation of the remaining work). If you choose points and don't use tasks, it wouldn't make sense to update remaining work unless it's totally done IMO (a PBI is done, or not).
IMHO you shouldn't use remaining for the SCRUM points, because the points should be really subjective and you probably can't say how far you have gone.
I would recommend that you break the task into smaller ones (these ones would be the steps you need to implement the features) and then estimate them into hours. This way you can easily track the progress of the feature
Use hours for both the initial estimate and the remaining time. Tasks are usually estimated in hours.
You can use Scrum point - or any other unit - to estimate the backlog items.
I would not bother with remaining. A story or a task is boolean (either done or not done).
In our team we started to accept only tasks that are expected to have less than a day. That way no team member should be working on the same task on two consecutive daily scrums. The third day for sure rings alarm bells!
Also breaking up in task is easy and fast, because it doesn't take much estimating. Is it less than a day: OK, otherwise break it down.
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 6 years ago.
Improve this question
I am part of an Agile scrum team working on a software product release. The sprint duration is 2 weeks (~10 days).
There is a peculiar metric used here, called 'mid-sprint acceptance'. Essentially, the expectation is that half the user-story points committed and planned by a scrum team in a sprint needs to be completed by the middle of that sprint. This, they say, results in a linear burndown of points which is a strong indicator that the sprint is going on well.
As a team, our mid-sprint acceptances are usually bad, but we are known to complete all the committed user-story points by the end of the sprint.
I have the following questions:
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Much thanks in advance.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
I have not heard of mid-sprint acceptance before. I dont believe it is a valid Agile/Scrum practice. This site would appear to agree "Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage."
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Any rigid metrics are generally not a good idea to use with developers for the reasons you mention. Also for the likelyhood developers will be more interested in getting a pass mark in whatever is being measured and not in producing a quality product. This is one of Joel Spolskys bug bears - here, here and here
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
A successful Scrum team should be completing all that they have committed to do by the end of the sprint. The burndown chart should be visible to guide progress towards this goal and certainly in the latter half of the sprint will indicate whether the sprint is likely to be a success. In successful sprints I have been involved with it is normal to make steady progress towards completing the user stories but this can not be reflected into completing half the user stories in half the time and I would counsel against a metric of this sort.
Have you tried to limit the amount of work you have in progress. If you get all the team to focus on a couple of stories and not move on until those stories are finished you should see your burndown become a lot more linear.
It might also be worth looking at the size of the stories. I personally don't like to see a story that takes longer than a couple of days to complete start to finish.
It is not a Scrum practice. It could be interpreted as a metric, but a bad one. Regarding your doubts, you're right.
Scrum has a perfect tool to follow the progression - The burn-down chart. No need to add any arbitrary milestone.
It seems your management doesn't understand the basic concept of a sprint, they should get some counselling or follow a basic training. If it is then still important to your management what's done within a week, try suggest to cut the sprint length into half instead.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Yes, it is.
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
If you break the tasks into really small ones you can achieve a good metric of work evolution. Therefore, design tasks to be complete in one work day and you can achieve a good burndown metric use. If you have long unpredictable-length tasks the burndown metric is irrelevant, as you said.
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
The problem is not the team, but the tasks design. The issue regards the task granularity. Your team can get the job done in the sprint time metric, but now you need to refine the tasks to 50% of them be completed at the mid-sprint time metric. Break the tasks into smaller tasks and you can achieve the desired (linear) burndown chart.
It's non-standard terminology, but there is something to what your manager is saying.
A burndown chart that is end-heavy (that is, stays high for a large portion of the chart, then tails off suddenly at the end) is indicative of a practice where tasks are coarse-grained -- that is, a task will likely take an entire sprint to complete -- and accomplished by individual developers. With this pattern, all tasks remain incomplete until just before the end of the sprint.
That's really not the way it's supposed to work: if the backlog is in priority order, then why are issues that don't have the highest priority being worked on? In addition, this sets the "bus number" for each task very low, which can significantly increase the risk of tasks remaining incomplete by the end of the sprint.
To fix this, tasks should be broken down into much smaller chunks. If you're doing planning poker, and a task is estimated at 8 points or more, then it is likely that the task is underspecified. It must be broken down. Try and keep it to 2s and 3s (or smaller!) if possible. In this way, you can have several developers working independently on the same overall goal, and your burndown chart should begin to look smoother, and less risky, even as the same work is getting done.
Mid Sprint acceptance is not a agile practice or it doesn't work in reality. If you have correct estimation for each user story and task (e.g in Rally) then burndown chart clearly shows whether the sprint work is in alignment with the plan and can be completed in time or not. Acceptance is done only at the end of Development & Testing of user story not tasks.
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've been recently implementing Scrum and one of the things we often wonder is the granularity of tasks within stories.
A few people inside our company state that ideally those tasks should be very finely grained, that is, every little part that contributes to delivering a story should represent a task. They argument that this enables tracking on how we are performing in the current sprint.
That leads to a high number of tasks detailing many technical aspects and small actions that need to be done such as create a DAO for component X to persist in database.
I've also been reading Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum, and I've taken the understanding that tasks should really have this kind of granularity; in one of the chapters, they state that tasks should take between 4 to 16 hours to complete.
What I've noticed though, is that with such small tasks we often tend do overspecify things and when our solution differs from what we've previously established in our planning meetings we need to create many new tasks or replace the old ones. Team members also refrain from having to track each and every
thing they are doing inside the sprint and creating new tasks since that means we'll have to increment our total tasks in our burndown chart but not necessarily adding a task that aggregates value.
So, ideally, how granular should tasks be inside each story?
Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit
It also gives a nice feeling to complete tasks at least a couple of times a week.
It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.
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
Im the context of pair-programming ...how do you estimate? A 5 point story ...split in to 3 tasks...each task being swarmed by 2 members. Does it mean it mean it is finishable in half the time?
You estimate using points. The number of points achievable by a pair is called velocity. Check this: http://en.wikipedia.org/Planning_poker
I always stress story sizing over estimating. If you can minimize the variation in size between stories, then estimates become much less interesting. That is, estimation activities lose their value when the difference in size between any two stories is small, which helps fast teams recoup the cost of estimation and put it toward something productive (like building product).
With that in mind, I would suggest proactively pruning the backlog and splitting five point stories into smaller ones (still thin vertical slices) whenever possible. Until your team is experienced, I'd suggest you continue to have estimation parties, but prompt a default estimate of 1 point to each card, with a quick consensus check or discussion as to why any justify a bump to a 2 or 3. For anything that's clearly bigger than a 3, I'd suggest challenging that one of two problems is present: the baseline value of "1" is too small or the story should be split (either made more specific or tracked as an epic).
As the team establishes a decent velocity, the activity can hopefully shift its mindset from estimation to mere story vetting. That is, the question during planning of "how big is this story?" becomes "is this story abnormal?" The latter question takes significantly less time to answer.
Most Agile methodologies suggest that you should estimate in points. However, there are many successful teams out there - including several advanced and highly productive Kanban teams - who estimate in hours. Points come with their own games, perverse incentives and problems. YMMV. Anyway...
I've heard figures of 25% more dev-hours for a pair completing a task. So, the task would be finished in 62.5% of the time, using two developers instead of one. However, the quality of and knowledge-sharing often increases too. Since bugs = rework and rework takes longer than doing it the right way the first time, pair-programming usually pays for itself. This differs for different tasks and levels of skill, eg: simple bug fixes, novice programmers, etc.
In my experience 2/3 of the time is a pretty good ballpark figure. It's longer than 1/2 but less than it would be with just 1 person.
Sallyann Freudenberg is a good name to look up regarding pair programming research. You could also check out the refs on the Wikipedia page:
http://en.wikipedia.org/wiki/Pair_programming
The figure is mostly borne out by the data in this report by Alistair Cockburn and Laurie Williams: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Pair estimates how long it is going to take them. Any estimate is based on experience - the longer experience team has with the project, with technology and with working together in pairs the better the estimates will be. Any arbitrary percentages like add 25% for pairs etc. are of any use only at the very beginning - with new project and new team on new technology - where you have nothing else to base estimation on yet. As soon as experience starts building the estimates will improve.
Remember though, that they are just this - estimates, that is our best guess of the future derived with the help of experience and knowledge from our understanding of the present. It's like weather forecast - the more data we have, the more experience forecasters have the better it is, but it is just a prediction, not reality.
Which is why points are so great, because they help you estimate one parameter you can - how "big" the tasks at hand are.
1) A simple, concrete way to think about estimating units is the number of check-ins it would take to complete the story.
If you're doing TDD, continuous integration and refactoring you'll be working in small, chunks of work, keeping the build green and checking in regularly so under those conditions single check-ins can be a meaningful unit of estimation.
2) Alternatively, think about blocks of uninterrupted pairing time in a day e.g. after stand-up to coffee break, after coffee break to lunch, after lunch to mid-afternoon break, mid-afternoon to going home time - say 4 periods a day.... so say 4 units is a single day. That gives you a bound on what you could expect to do in an interation...
Personally I go for the number of check-ins, because I can sketch out roughly the tasks involved and get an idea of check-in numbers.
The great thing about number of check-ins is that it doesn't matter if you're pairing or not - you're just tracking what you can get done.
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
with agile estimating, is it true some say to choose intervals like 1/2 to 1.5 days only?
It tends to be a good rule of thumb (agile or not) that your tasks should be broken down into at most 1 - 2 day increments.
The idea is that if you have larger chunks than that then you haven't broken the task down enough and you will more likely miss the estimate and miss it by larger amounts of time than had you broke it down. Often when you break it down you discover your initial estimate was off and since you have broken the task down into more concrete tasks your estimate is now more accurate, more trackable and meaningful.
For tasks that are coming up on your to do list soon you should pay attention to this but for long range planning where you haven't necessarily thought out the feature in detail I think larger estimates / tasks not broken out for the feature is OK.
Here's a link to Joel Spolsky talking about this. Take a look at item #5 about half way down the page.
http://www.joelonsoftware.com/articles/fog0000000245.html
In my experience, any estimate that's longer than 2 days is probably hiding serious work that should be broken down further. Such estimates have a very high probability of going over. Try to break everything down into smaller chunks so that no individual chunk costs more than 1-2 days.
There are advantages to keeping the estimates short. It forces you to break up large tasks into small, discrete tasks that can be measured and discussed quickly, which helps promote the entire Agile development process.
That being said, I almost never keep a "rule" as a hard and fast rule with things like this. I'd say this is a good guideline, however.
My team consists of junior programmers (university students) and we've found that it's generally easier if we break all the large tasks down into a bunch of smaller ones. It involves more forward-thinking but in the end we are more productive and can it's easier to evaluate our progress. It also brings a sense of achievement when you have something completed at the end of the day.
I would agree with that guideline. Anytime I have ever taken on a 5 day task, it has degenerated to a three week nightmare. Large estimates indicate you didn't learn enough about the problem up front to know what is involved, because if you had, you could have found ways to break it up better.
I don't agree. If a team's iterations are two week long, the 10 days mean that 1 day would be spent for iteration close (show & tell), iteration planning and tasking or planning poker.
When playing planning poker, a team either geometric or Fibonacci progressions for estimates. For example, cards would contain values such as 1, 2, 4, 8, 16 or 1, 2, 3, 5, 8, 13. Each number reflects the number of days of development for a pair of programmers.
For each card, once discussion has occurred, each member simultaneously plays the card that reflects their estimate. If the majority of the team converges on the same estimate, the estimate is accepted. If there is much variation in the estimates, further discussion occurs (members explain the reason for their estimates) and another round of voting takes place. This occurs until consensus is reached.
If a number greater than 8 is picked, then the card is deemed to be too big and the card is refactored into at least 2 smaller cards. The reason being is that such a large estimate indicates the card is too big to be completed in a single iteration and any estimate is very likely to be inaccurate.
Using such a method brings commitment from the team members to delivery all they have committed to and for a new team the estimate become so accurate that carry over of cards soon become a low risk.
A very good post about agile estimation and planning you can find on the blog of agile42: Just enough, just in time
A lot of good answers here, so I'll play devil's advocate and approach it from a different side.
There's a possible problem with breaking down things into very small estimates (# of hours) when doing things such as release planning. David Anderson discusses it in his (excellent) book Agile Management for Software Engineering.
Basically, the idea is that with a task that is very small, a developer will pad his estimate by a fair bit (say, turning a half hour into an hour, or doubling it) because of a certain amount of ego that would be bruised if the developer failed to complete such a small task in the estimated time. These local buffers add up quite a bit and result in a global buffer that's far bigger than it needs to be.
This is less of a problem if you stick with .5 days as a min - it's basically assumed that there's some buffer in there, so you won't need to pad it any more.
I feel there is a bit of mix of information and overlapping in this thread... allow me to make my point :-)
1) The Fibonacci sequence, that is very much use through the Planning Poker technique from Mike Cohn, is about estimating "Complexity" of User Stories, which are - as Cam said - normally written on cards, and entail more than one task, at least all of those which will be needed to make a Story shippable (Ken Schwaber, Alistar Cockburn, Mike Cohn...)
2) The tasks that are included to complete a Story, are normally estimated in Ideal Hours or Pomodori (Francesco Cirillo, "The Pomodoro technique"). If you estimate in Ideal Hours normally the rule of thumb is to keep them between 1/2 day (3 ideal hours) and 2 days (12 ideal hours) of work. The reason for this is that doing so the team will have more qualitative status information by having at least every two days a team member reporting a Task as done, which is much more "valuable" than a 60% done. If you use Pomodori they are implicitly "timeboxed" to 25 min. each
The reason to keep tasks small comes basically from the "Empirical Process Control Theory" for which through transparency and regular inspection & adaption, you can better check the progress of your work, by quantifying it. The goal of having smaller tasks is to be able to clearly describe and envision in details what will be actually done, without adding too much of "guessing" given to the natural uncertainty deriving from having to predict "the future". Moreover defining an outcome and a shorter timebox allow people to keep the focus with enough "sense of urgency" to make it a challenging and motivating experience.
I would also catch up the point of the "motivation" and "ego" - from Chris - by adding that a good way to have people committed and motivated is to define the expected outcome of a task, so to be able to measure the results upon completion, and celebrate the success. This idea is encapsulated in the Pomodoro Technique, but can be achieved also using ideal hours for estimation. Another interesting part of the Pomodoro Technique is that "breaks" are considered "First Class Citizens" and planned regularly, which is very important especially in creative and brain intensive activities :-)
What do you think?
Best
ANdreaT
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!