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.
Related
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 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
Scrum and agile says that items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
Practically, that never seems to work for our team. Either the item is too small for all team members to be productive (including taking pairing into account). So we end up perhaps doing two or three items across the team at any one time.
I'd be interested to hear how other teams do it, and also how many items they usually commit to in a given sprint.
items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
I don't know who says this, I at least don't remember having heard or read anything like the emphasized text so far. Of course, it depends also on whether an item for you is a story or a single task.
If it's a story (usually consisting of several tasks), there might be a chance of achieving this. However, as you say, sometimes the story just doesn't include enough tasks to keep everyone busy. Also often the tasks related to a story strongly depend on each other, e.g. there might be a design session (involving part or whole of team), then one or more coding tasks, then code review, functional testing, documentation etc. Obviously one can't do functional testing before the coding, and so on.
Since everyone has to do something, there will be at least as many tasks open at any given time as there are team members (or pairs). Taking into account that sometimes tasks are on hold for various reasons (inter-task dependencies, information needed from external parties etc.), usually even more.
In one Scrum project with a team of 4 developers, we had a very similar situation. We did strive to take stories in priority order as much as possible, and usually we had multiple stories and several tasks open at any time. In the beginning we often had problems with several half-finished stories at the end of the sprint. So we realized it is important to keep the number of open tasks / stories to a minimum, i.e. always attempt to finish open tasks /stories first before starting a new one. But practically, that minimum was never meant to be 1.
As for the number of stories per sprint, we just put in as many as we could comfortably fit in based on our (story, then task level) estimations. That was of course greatly influenced by our velocity, which in the beginning was estimated too high. After a couple of months we chipped it down to 60%, and that value seemed to work for us.
The advice to approach each item by the whole team is there to avoid creating mini-waterfalls within sprints, where items are passed from one specialized group to another. That leads to stuff like testers having nothing to do in first days of the sprint, then working overtime for the last couple of days when coders fiddle their thumbs. Teams should approach the problem as a whole with everyone chipping in, even outside of their respective "specialization". Yes, coders can test, testers can code and both can design architectures etc. - and in the process learn something new (amazing). That is not to say everyone should be very good at everything - it is just to say attitude like "I don't test, I'm a coder" or "I won't write this script, I'm a tester" should have no place in a Scrum team.
It is also advised to tackle items one by one inside of sprint to make sure something is actually delivered at the end. Limiting work in progress (WIP) prevents situation, where everyone did some tasks on each item, but no item has been completed by sprint's end.
However, this shouldn't be viewed as advice, not a very strict rule. For example when you have two small stories and a team of 10 it probably doesn't make sense to have all of the team swarm on just one story.
Bottom line is: no one should tell the team how to divide work among themselves, but delivering what they committed to at Sprint Planning should be expected.
I think it depends on the makeup of your team. If you have a team where anyone can take on any given task within a user story, then this works well. If you do not, then there will likely be idle time for some individuals.
The point in working the user stories based on priority is simple... you get the highest priority user story completed first. This adds the most value from the perspective of the customer who actually set the priority.
As for how many user stories to commit to during a sprint, that depends on a few factors:
Team Availability, Team Velocity, and Sprint Duration. So, I'm not sure how much value you will get out of knowing how many stories other people tackle during a sprint.
Noel, is your team trained to work in a Scrum team ? I mean did you send them to Scrum Course prior beginning the project ?
I've seen so many team failing with Scrum just because they misunderstood what was written in a book on a blog.
Also having an experienced Scrum Practitioner or Scrum Coach will help you a lot.
To answer your question specifically, check this nice free ebook that is different than others:
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
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.
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!