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 started a project that will be managed with Scrum/XP. We wrote the whole product backlog upfront for evaluation purposes. We're making sure all stories are customer-centric and we're evaluating them by
story business value: MoSCoW technique - Must, should, could, would/won't have this implemented
story effort/complexity (= story points): 1, 2, 3, 5, 8, 13, 21, 100 - related to story complexity/effort rather than ideal days duration
100 story points may have some stories with Would/Won't have because they actually are bigger complex stories that will be broken down later if needed.
Calculated story importance is based on value&effort by not overlapping MoSCoW stories.
But without 100 point stories our stories so far (also broken down) has complexity between 2 and 8 which we think is an appropriate story size to avoid micromanagement. But some stories became related or dependant on each other. We have stories that may take more if done first, and less if some other story would be done before them.
Questions
Is it possible to adjust story points later on during development, as we can do with story tasks where we can re-evaluate them, add new, remove existing or is this not the case with stories? Because changing their complexity, will also change end date estimates based on planned velocity. What's the best practice in this case?
You absolutely can estimate your stories again and you should. The points are only locked when the team commits to them at the Sprint Planning Session immediately prior to the start of a Sprint.
One practice I've used is when doing the individual Sprint Planning you should evaluate each story again. The team learns over time and will become more accurate with estimates and identifying dependencies. Remember what goes into a Sprint is up to the team, the product owner defines the overall backlog. If the project is time bound don't try to make the estimates fit the End Date, if you do you are setting yourself up for failure.
Remember that with Velocity you start with a guess at what you can accomplish. It usually isn't until the 3rd or 4th Sprint that you hit identify a realistic Velocity that the team can manage. Yes this does mean that you may have assumed the team could deliver 20 points per Sprint and actually can only do 15 points. Yes that means delivery time goes out or stories fall below the cut line.
As for dependent stories you should work with your product owner. If the team talks to them you can usually rearrange stories. Most people are receptive to someone that tells them "If we do A now it will take the full Sprint, but if we do A later it will take 15% of a Sprint" that makes it pretty convincing.
A useful practice to try is scheduling the stories within the Sprint. During the planning session once all stories are validated and discussed the team pulls up a calendar and discuss when they want to have things done. By putting target dates on a calendar it helps to identify overlaps and dependencies between the stories. This can identify things that are serial in nature and may cause a Sprint to fail.
Hope this information is helpful.
From your explanation you're doing a great job already. Of course there will always be stories with a dependency. Some may not even have directly visible customer value; i.e. the initial effort to set up an architecture and some frameworks). But if you leave them out you'll create a lot of technical debt. If you can, I'd suggest that you try to make the equation complete and somehow show the relation between the tasks.
For instance:
- task 3 is 8 points if done after task 2, but 12 points if done independently.
This way the product owner will feel the pain of ignoring dependencies, but can still make a choice to do the most valuable stories first. If the product owner is sure that all of the stories make it in the next sprints, then you can steer to have them implemented in the most efficient order. For instance, by blocking items for which dependencies have not been fulfilled (i.e. you can only have the 'change my logo on website' feature after the story 'webenabled version' is completed.)
Good luck!
I can only describe my expirience.
When we were planning first sprint we decided that we could accomplish 18 points. So we took several stories and total estimation were 15 points. As I mentioned above we were making our first steps in scrum and that's why we decided that 3 unused points and form-factor 0.6 guaranteed our success.
But our estimations of each story were only approximate. We had also some dependent stories. And we didn't make plan of implementation of each story because we thought that it's unnessecary with agile methodology.
As a result we failed our first sprint with only 8 complete points.
Before our second sprint I decided that we should take something from old good simple cascade and iterative methodoligies (and I was a scrum-master). So, on our next spring planning to make correct estimations we planned each story (about 20 minutes per story), with simple diagrams, all dependencies, details of implementation and so on. The planning was difficult and it took 2 meetings.
But the second sprint was much better and we've done almost all (actually we've done all but with some bugs). I think that we'll take less form-factor in 3rd sprint and it'll be successful.
There are some patterns that would help you in splitting User Stories in a way that they would remain INVEST, which means you would try to save dependencies, size, testability and value in particular. You can read more about that here: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard is actively applying and improving them, and he is not alone ;-)
Just be aware that splitting and keeping dependencies (which is like creating a critical path in a Gantt chart) is going to trump the capability of the team to be creative, and to negotiate on those stories, and might also hide a "non-valuable-proposition".
HTH
ANdreaT
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 have been using agile approaches (XP and Scrum) for my projects for several years with great results. But in all cases, all members of the dev team were committed 100% to the project.
Now I am faced with doing this when the team is not stable. For instance, one iteration there may be four people working, the next maybe only two or three.
I realize this makes it hard (or impossible) to estimate using the normal velocity approach since it will fluctuate to much and not be stable. What follows is that one cannot really expect to be able to release at the end of each iteration.
Maybe another approach is needed here. Just grab stuff from the backlog and just muddle through and release whenever it is possible. I really don't like that though...
Any thoughts?
From the question I assume you have some developers (probably, 2) 100% commited to the project and some (another 2-3) only participate at a times.
One thing you can do is set different process for core developers who are 100% commited and everyone else. Use you normal agile process for core people and release their work at normal iteration cycle. For non-core people, do little planning and assume their (and your) estimates would be way of at a times. Ideally their changes should be isolated and merged into stable branch of code by core members, but not every project's architecture and team roles allow this.
The point is to separate and isolate source of chaos and leave the heart of a project and team unaffected.
Maybe instead of agile approaches, you can slow things down with other iterative and incremental approaches. Instead of having iterations measured in weeks, having longer iterations (perhaps measured in months) would be better if you keep adding and dropping people from the team.
This doesn't mean that you still can't use some Agile techniques. I would still maintain your Backlogs and burn down charts, with the realization that instead of having a release every 2 weeks, you'll release every 6 weeks (~2 months). If you have new developers joining more experienced developers, use pair programming, assign the new developers to bug fixes, or assign the new developers to maintaining unit tests to help them learn the code base.
Velocity is only an estimation.
Naively, if you have a given velocity v with a team of 4 developers, then schedule your iteration with a velocity of (v/4)*number_of_developers
You can fudge this value if the members you are losing are particularly stronger or weaker than the average.
This is basically what PivotalTracker does with its team strength metric.
So, you have a project with a continually changing team size and your boss wants you to give him an accurate estimate of how long it will take? You can do this, as long as you keep in mind the difference between accurate and precise. Your precision will depend largely on the number of items and how granular (decomposed) each item is; the more items you have the more the Law of Large Numbers works for you, averaging out over- and underestimates.
Your accuracy is a function of confidence. Note that estimates aren't single-point values, they're a range with numbers with a percentage of confidence. For instance, a proper estimate wouldn't be "2 weeks" it would be "50% confidence of 2 weeks, 80% confidence of 4 weeks."
If I were the person assigned with the unenviable task of providing an estimate to completion for a project being managed as arbitrarily as in the original post, I'd try to figure out a range based upon the minimum number of folks assigned (e.g., "48 to 66 weeks given 2 developers [50% to 80% confident]"), and a range associated with the average number of folks assigned (e.g., "25 to 45 weeks with 5 developers [50% to 80% confident]"), and use the low figure from the average number along with the high figure from the minimum number (e.g., "25 to 66 weeks given anywhere from 2 to 5 developers [50% to 80% confident]"), and even then I'd put a disclaimer on it ("plus 10% for the lost time due to context switching").
Better yet, I'd explain exactly why this arrangement was, to be polite, sub-optimal, and why multi-tasking is a primary signpost on the road to project Hell.
As someone else suggested, changing the workflow from iteration-based to flow-based (Kanban) might well be a good strategy. With Kanban you handle changing project priorities by changing the priority of items in the backlog; once an item has been grabbed by the team it is generally finished (flows all of the way through the workflow, stakeholders aren't allowed to disrupt the team by screwing around with work-in-progress). I've used Kanban for sustained engineering projects and it worked very well. Re how it would help with estimates, the key to continuous flow is to try to have each work item be roughly the same size (1x, 2x, 3x, not 10x, 20x, 100x). You should track movement of items through the workflow by tracking dates of process state changes, e.g., Queue 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrate 2/7, etc., and then generating a cumulative flow diagram regularly to evaluate the time-in-state durations over time. Working out how long the project should take given that you know the size of each item and the time through the workflow for items is a trivial computational exercise left to the reader. (The more interesting question is how to spot constraints... and then how to remove them. Hint: look for long times in states, because work piles up in front of constraints.)
Let the individual developer that will be working on the story estimate the effort required to complete the story. You can take into account historical variances in that developer's estimations, but the idea is that you can take their estimates and then figure out how many stories you'll be able to finish in that sprint.
Don't forget that average velocity is largely used for lookahead release planning; the team is responsible for selecting in each iteration how many backlog items to take on (although knowing historical velocity can assist them).
If your team size (and hence velocity) is fluctuating from iteration to iteration, you can still do useful release planning by using average velocities over the past N sprints, assuming the team fluctuations will continue and hence their long-term average velocity will actually be stable.
Your main problem here is that the team will find it hard to give predictable estimates and deliveries since the team is changing from sprint to sprint. This can also hurt the team commitment and continuous improvement.
This case might actually be well suited for a Kanban approach. Check out Henrik Knibergs introduction to Kanban for a quick overview.
Good luck!
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
Note : Before asking this question I did an exhaustive search, and found little bits of the answer in various other questions, for example:
What is the best resource for
learning Scrum?
Scrum Process
Management - tips, pitfalls,
ideas
Two questions regarding Scrum
However, I feel like this question hasn't been directly addressed (if it has, please let me know).
Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not? Can you adjust those tasks and estimates?
Background: Our new VP of development came from a Scrum environment, and so we're all learning about the process, but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.
But it was my understanding that agile practices, specifically Scrum, were based upon the concept of tasks being buckets that store individual deliverable goals, and you add/remove/adjust them as the clients' needs evolve after each sprint.
I realize this could potentially be argumentative, but I assume that viewing Scrum as a process, only one of those concepts is the "correct" philosophy for that system.
Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not?
I track the estimated remaining work. This is a must have information. Without this, you can't draw the Burndown Chart. Without the Burndown Chart, you don't know "where" you are, you don't know if your Sprint is still on track or not. This would make this decision tool pretty useless. Yes, the Burndown Chart is not a tracking tool, it's a decision tool.
Can you adjust those tasks and estimates?
Sure!
Actually, the team owns the estimates, nobody else, and it is the job of the ScrumMaster to guaranty that this principle is applied. This should already answer the question. But there are other reasons.
As I said, a Sprint Backlog and a Burndown chart are decision tools and should thus be representative of where you really are. If you hide the reality, if you are not transparent, these tools won't help you to take any valuable decision, they will be useless. Think about it, what's the point of having good looking numbers if they are useless? What's the point of having a "nice looking burndown" if it doesn't reflect the reality.
So, during a Sprint, team members should obviously update the estimations of the remaining work as soon as they can do it (upward or downward). If a task estimate was initially 6h but the team discovers that more work has to be done and that the task will actually take 8h, the team should update the Sprint Backlog accordingly. If someone spent 4h hours on a task that was initially estimated at 4h but still need 2h work, these 2h should be reported on the Sprint Backlog. If the team discovers a task that has to be done but that wasn't identified, the team must add this task and its estimate to the Sprint Backlog. And being not accurate in the start is not a problem, as long as you update the backlog with the knowledge gathered over time. The sooner you make these updates, the sooner you'll be able to adapt and take decisions.
That said, it can be useful to keep the "initial estimate" and to compare it to the "actual time spent to complete". But not for tracking purpose, only to help the team to make better estimates. Actually, I would advice to not do this if you are transitioning to Scrum. There are often many other impediments to solve, many other things to improve first when you are learning Scrum values and principles. And if you do it, beware of the Waterfall daemons. Be ready to fight them, they may come back very fast.
The answers I see here aren't wrong, but I don't think they've really addressed your question.
I think you're asking, "Should I track the total hours actually spent on a certain task?" The answer is, "You can if you need to, but it isn't part of Scrum."
Scrum is a very lightweight process. It defines/requires only what is needed to make Scrum work. You can (and, in many cases, probably should) overlay other processes on top of Scrum in order to suit your organizational needs. For example, if tracking the total hours actually spent on a task enables you to better estimate similar tasks in the future (as it seems your VP wants), then that might be a good reason to track total hours, provided that it doesn't interfere with productive work too much. Or, perhaps you need to know the total hours for billing purposes. So just because Scrum doesn't require something doesn't mean you shouldn't do it.
However, for the purposes of Scrum itself, there is no need to track the total hours actually spent on a task. It is not needed for any of the Scrum artifacts, which only track the estimated amount of time remaining.
I don't know if our implementation is "correct", but what we do is:
Have Backlog Items added, which we put an estimated complexity number on (in relation to other backlog items).
Before each sprint, we go through the backlog items in priority order (prioritized by the product owner), break them down into tasks for which we make a time estimate (in hours).
When the number of available hours in the sprint are used up, the sprint is full
Then, during the sprint after each day of work we adjust the times on the tasks that we have been working on, so that they show the number of hours that we think is left before the task is done. This means that if I have a 6 hour task, work on it for a full day (we consider 6 hours a full day) and then feel that I still have 2 hours left before it's done, then I take down the "hours left" from 6 to 2. In case the task is time-boxed we need to check actual hours used instead, of course.
I have to add something here because
but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.
Is just plain not scrum so I don't know where your VP got his info. Tasks (know as Sprint Backlog Items) are not created until Planning the next sprint. They are created just in time and certainly not before the project starts. Before the project starts (Sprint 0), the Product Owner creates the Product Backlog and fills it with stories. He can add to it at ANY time during the project. It is his to manage. The team estimates these stories roughly against one another in story points or some other relative measure (ideal days?).
The estimating of tasks in hours is only a tool the team uses to figure out how many stories to commit to in the sprint and then to plot progress to predict success (burndown). Once a team has gelled and has a historical velocity; it may decide to not do any tracking in hours at all and just track their burndown in story points or # of stories. Estimating in hours is a form of waste in itself if the team does not need it to achieve commitment to the sprint goals.
I would ask the VP what these "very careful" estimates are going to accomplish.
Estimate time, but don't really care if it's spot on
Just make sure you are careful and estimate tasks thoroughly. Basically you don't really measure time, because it's more error prone. The best way is to use tasks' time estimates as story points. This way you will gain:
If your time estimates are off, research shows that they tend to be consistently off (accuracy factor doesn't change too much), so time estimates can easily be used for story points calculation.
If you empirically managed to do x number of story points in previous sprint, you'll probably achieve similar results this time round even though your time estimates are incorrect.
You will have to be rather good at estimating all story tasks. Otherwise your sprint story points tend to grow during execution and you won't meet your deadline - even though your velocity will remain practically the same
Estimates can change but similar to #3, keep some sprint slack time for these changes to meet sprint deadlines (demo day).
But keep time estimates to actually see which tasks must split or join.
We track both the time spent working on the tasks, and the time remaining to complete them. The remaining time allows to determine the progress made during the Sprint, and to anticipate whether we will be able to achieve the Sprint goal. We update the remaining time for the tasks, adjusting it (sometimes increasing it) on a daily basis.
The time spent is - supposedly- for micro management. It also gives the team a chance to get some feedback on the accuracy of the estimates - and to get better at estimating - and to show how interruptions prevent the team to work on the Sprint backlog and therefore, slow it down.
In the Scrum process, individual deliverable goals are called Backlog Items, and can be seen as bucket of tasks. The Backlog Items are prioritized by the Product Owner, estimated by the Team, first as a whole and then task by task. Content, scope, priority and estimation of the Backlog Items can be revised.
We estimate both the Backlog Items and the tasks in time units (days or weeks for the Backlog Items, hours for the tasks) and we apply a focus factor (ratio of time dedicated to work solely on the Sprint tasks) to account for time not spent working on tasks to achieve the Sprint goal.
With respect to time tracking, what you're looking for is a burndown chart.
Fredrik explained what a burn down is, without using the term. Essentially, you regularly reestimate the time remaining for a particular activity.
So to your question of whether or not we track time spent, not necessarily. Scrum likes to work with time remaining instead. (You could substitute hours with story points, the principle is the same, as Robert explained.)
To your second question of whether you can adjust your tasks and estimates, most definitely yes. Agile follows the 'reactive to change' philosophy; you prioritize what's most important to the customer.
However, some teams to prefer not to add/delete/re-prioritize tasks in a particular sprint once it's begun, since that is almost an ad-hoc way of working, and even scrum requires some structure and discipline.
The statement "thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks." is almost certainly not in the spirit of agile.
We use the Pomodoro Technique to track the time remaining. One of its advantages is that the amount of time spent is recorded in a disciplined way.
After estimating stories in story points, we estimate tasks in terms of pomodori, and use this estimate (which may be reestimated ad hoc) to judge the amount of time remaining. At the end of the sprint it's easy to see which tasks we originally estimated the least accurately and improve how we estimate in the future, due to the way we mark the number of pomodori estimated and completed on each post-it.
In terms of the sprint, the estimated hours remaining are just a measure of progress so we can see where we are burndown-wise. They're a clue to whether we're on track or not. The score that matters is story points completed.
By definition, an item is done when all of the tasks that need to be completed in order to fully implement that item have 0 hours left. What you need to track inside the sprint is remaining hours on remaining tasks. Not hours spent on a task. Why? Because our knowledge of how long something will take is imperfect and we gain little by trying to come up with a super-accurate estimate when we should be working on the product.
You are always allowed to add tasks under a sprint backlog item as you identify more work that must be done to fully implement the item, and you should update the remaining hours to completion daily (or set them to 0 once you've completed the task).
You should tell your VP that knowing when you're going to ship the product based upon your most accurate information (today) is far better than setting a number/making an estimate in the past and never updating it. This doesn't mean re-estimating user stories (don't do that until the end of the release), it means updating the sprint backlog with new tasks, and the best estimate as to when active tasks will be complete in remaining hours.
BTW, the way to work on accurate estimates is to plan your release using story points, create an iteration plan based upon your estimated team velocity, and then to continually update the iteration plan based upon the output at the end of each sprint. After a very few sprints you will get a very accurate idea of the actual team velocity, making it easy to forecast when you will ship your release with the desired scope... or what scope should be completed by the original ship date. Using actual project data from your current project to predict project completion is a software engineering best practice, because it is the most accurate way to make a prediction.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have read the agile manifesto and spend a nice day surfing the web in search for this elusive answer. But sadly I did not get an answer that would cover all the bases.
When watching all the blog posts and newscasts of Agile preachers, you just hear about open scope or open "time" projects. How do you apply this to a fix cost project?
From what I found out the biggest problem is scope management. How do you determine if something is not inside the projected scope and how do you formulate arguments for your decision? Because of the agile way you are implementing your software there is no detailed design to argue upon. In most cases you only have a vague wish-list that the customer hands to you. And is so general that you can interpret any feature into it.
And with the rising percentage of fixed-cost projects this seams to me to be a real issue.
So the questions would be:
How do you manage scope in a fix cost project?
How do you determine if the features wished for, are outside the original scope?
To me, the short answer about Agile and fixed price is that you can't do it, at least not with a fixed scope.
I know some people will say "that's not true, we are doing it" but, with all due respect, I don't think they are really doing Agile and I'll explain why. Actually the explanation is quite simple: fixed price implies fixed scope and is based on predictability where Agile is all about variable scope, scope management and adaptivity. So fixed price with fixed scope is basically the opposite of Agile.
With an Agile approach, fixed price gives you a number of iterations for a given team size. During these iterations, the customer will be able to have the team build the most valuable features first and thus to maximize the generated business value. The whole idea is then to stop iterating when the cost of an iteration is greater than the generated value. This is how Agile works.
So when people says they do fixed price with fixed scope in an agile way, they actually introduce some constraints that are not really compatible with the Agile theory - like doing an up-front estimation of a given set of features and freezing these features and estimations - and they loose important advantages of Agile (unless they have a perfect knowledge of the technologies and of the business domain and master them enough to predict everything but I know few projects that are like this).
Here is anyway a good compilation of various Agile contracts: 10 Contracts for your next Agile Software Project that might be helpful. But I think they all require some education of customers, especially the one that are used to fixed price with fixed scope (and late deliveries).
Scrum does not replace having proper requirements, or even having occasional major releases or milestones. Rather, it gives you a means to keep your team productive and focused, and avoids the time-wasting side-effects of a waterfall process.
In fact, one of the biggest advantages of an agile process like Scrum is that it causes you to "fail quickly and loudly" on problematic areas of your project. If, after a couple of sprints, your team still can't effectively estimate the time and resources needed to implement a particular feature, it may be worth pushing back on the requirements in that area -- they may need to be clarified, simplified, or scrapped altogether. In a traditional waterfall process, however, those "problem features" can often be pushed back to the last possible minute, resulting in the usual deathmarch and under-delivery into which most projects devolve.
However, the role of the Product Owner is even more critical in teams using Scrum who have a large set of requirements. Left to their own devices, most development teams will focus on the most interesting/fun/geeky features (service APIs, caching, search) first, and leave the "messy" stuff like payment process, UX design, and i18n until the last minute. A strong user voice is essential to making sure those features critical to the end user receive their fair share of attention.
Okay, this will not be the ideal answer you are looking for, but may help non-the-less.
For your first point:
With agile, and Scrum in particular, the style is suited toward changing specifications and unfixed deadlines using iteration patterns. To be able to manage this in a fixed scope project will be a nightmare. What one would normally do is set a budget for the specified scope, and any addendum to this would produce billable hours above and beyond the scoped budget. To do this in Scrum would be pointless, as the product backlog will be continually filled by the stakeholders. If there is no "punishment" for scope changes in a fixed budget, there will be nothing holding people back from just loading on to you.
The alternative here is to have fixed scope sprint successions, so for instance:
5x Sprints = x Cost with minimal scope change.
For your second point:
The use of Analysis and Design is an invaluable tool. By using use cases, event tables, sequence diagrams, state machines and the like; you will be saving yourselves oceans of tears in the long run. Basically, once the planning has been done, any addendum to this that requires additional (please note additional, not things that have been overlooked) use cases and large code changes will be out of scope. In fact, anything that was not overlooked in the planning and is not in your specification, is out of scope.
In closing, you will need to have very well planned documentation as well as very solid agreements with your clients to be able to pull this off 100%.
I hope this helps.
I worked in a environment where we had fixed cost and fixed time projects. We has switched to a Scrum-esque methology from a Waterfall/VModel methology. Scrum can work very well in fixed cost/time projects as the concept is that the customer is put in control, however for this to work you have to be able to somewhat accuratly determine what work is required and what it will cost (time, money, resource). And this is a situtation where Scrum in an ideal candidate.
You break down the wishy-washy wish list/requirements/screenshots into tagiable deliverables. E.g. a customer may say "I want ecommerce, with Paypal", you need to break this down into actual deliverables e.g. "1. Customer Registration and Login, 2. Product Catalogue, 3. Shopping Bag, 4. Payment, 5. Order Acknowlegment". At this stage, it's still impossible to determine how long it will take, and ofc we need to deliver all of the above in order to complete the project (i.e. you can't have Ecommerce without Payment). So break them down again, and again, until you have granular deliverables, genreally delverable within hours, maybe days, but certainly not weeks e.g.
1 Catalogue
1a View all Items
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row
1aii View 10 items per page with paging
1aiii View a user slected number of items per page, with paging
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row
1b View by Category
...
1c Search
...
1d Attribute Filter
...
And so on, it can be done very quickly, and you can now probably guesstimate how long it would take todo x (ofc, I might break the above down even further, add more descriptive text to describe the work required, such as what persistant data stuctures Ill might need, the data in those structures, how data will be added, going further you might even desribe the required the begin and exit states).
Once you've go this, you'll notice that some features and depenant on others, e..g you can't have paging feature on a catalogue unless you have a catalogue to start witj, and the catagloge will require the CMS screesn to add and edit items etc etc. Highlight these 'can't live without feature' in whatever tool you using and this forms the core project, and within a day or two you have a bunch of features that can be developed somewhat standalone, with costs, which when added up make the cost of the project. And now the customer is in charge, they decide thay want to added a feature and increase the cost, cool, its up to them afterall.
All the above is obviously only a small portion of what scrum or any agile process is.
I don't think a fixed price contract with scope creep and a Scrum process are incompatible. You just need to agree up front with your customer how it will work. If you create your initial backlog with your customer, estimating as you go, you can use that as your basis for the fixed price cost and schedule. You can even agree to a rate of "X" story points equals "Y" cost and "Z" schedule at the beginning.
You then do the normal scrum thing, having the customer allocate stories to the current iteration, etc.
As the customer engages in scope creep, you work with them to add the "creep" as user stories to the backlog. Each time you add a new story, point out that for each X points added to the backlog, they will have to increase cost by Y and schedule by Z, or, they will have to give up story points of equal value. Since they are picking what you work each iteration, the points they give up (if that's the choice) will be the least valuable features. When your schedule runs out, you will be left with a backlog of the least important features that they can choose to drop or give you a new contract to finish.
The trick, of course, is to be good at estimating cost and schedule for each story/task ;-)
The project could be broken down into smaller parts and fixed rates could be attached to those. The other phases of the project could then be adjusted.
You have to be able to sell the agile process against your competitors. If a client has a history of fixed bid projects that were delivered on time, spec and cost, why would they waste their time taking bids from other developers?
Fixed Cost does not mean single sprint. Scope gets transfered to the Product Backlog, and as Sprints progress, scope is adjusted, negotiated and delivered. Scrum allows for rapid value delivery, and provides quick validation, and the opportunity to identify potential gold plating.
Scope change may result in the addition of backlog items, and the deletion of others. Its a balance of ROI vs the fixed budget provided.
If the scope does increase (and add value), and the cost is fixed, then the triple constraint (cost, time and scope) must be managed accordingly.
Remember that fixed cost does not mean fixed length.
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 3 years ago.
Improve this question
It took me some time, but I've finally managed to write down all the tasks that need to go into Version 1.0 of the software product I'm working on.
The list is almost 1000 items long.
We are a 3-person team, and we've somehow managed to get this far using MindMeister, Google Docs, #todos in the code etc. Now, I have everything neatly grouped by feature, but how do I prioritize all this and turn it into a schedule?
Any advice would be greatly appreciated - I'm not looking for software recommendations, however - I'm seeking advice on how to take this enormous bag of tasks - ranging from bug-fixes to application modules - and find out in what order I should do them.
Prioritize ruthlessly. 1000 action items is a lot, and the odds are that as you go you'll modify some, toss others, and add new ones. Your list will not survive the things you learn by actually building the software, and if you don't do the most important stuff first, you'll end up with a mess.
For every item or feature, you have to answer the question: Can the product be at all usable or useful without this? If yes, it can wait; everything else goes to the head of the queue.
After that, I like to group milestones by focus: I'll do a features milestone (or multiple ones if there are natural small clusters of features), a UI milestone where I'll focus on AJAX/rich client interactivity, a performance milestone where I profile and do database & server tuning, etc. Or break them up some other way - but definitely break them up. Work in smaller bites with specific focus for each iteration, and make sure each iteration is solid before moving on.
My recommended approach will be based on Agile methodology best practices...
So, you have what in Agile terms is called a "backlog" defined- that's great - and an important first step.
A good Agile pace that is commonly used is a 2-3 week iteration length...and at the end you have a set of releasable features. This will establish the "heartbeat" of your development process. Next, you'll decided how to organize and group the features into Stories and Tasks.
You'll want to grow the underlying architecture and let it naturally emerge based on the ordering of the Stories and Tasks that you select from your backlog.
Its important to mitigate risks early - so you'll want to select early those items that are either performance or implementation unknowns that might pose the largest risk - and could result in the largest rework impact. For example - establishing the messaging infrastructure - might be an early architectural feature that might be included if you select a Story that required a persistent message to be delivered to complete a unit of work.
Can you group the set of features into functional categories that might naturally evolve to describe the 1.0 release as a System of Systems? For example, the Administrative functions, the User Profile Management, Reporting, external integration layers, Database Access Objects, etc.
What are the simplest Story / Use Cases that you can write - that will map to some of the ~1,000 features / requirements you've defined? Select a set of Stories (or individual Tasks from a Story - if the Story itself is too large to implement in a single interation). It will take some additional effort - but recomposing your requirements into a set of Stories/Tasks is important.
You'll find that you will refactor during subsequent interations - but that your steady 2-week heartbeat iteration schedule will keep delivering real functionality.
At various points you may want to schedule an architecture iteration just to focus on some cleaning-up / refactoring - and that's ok too.
Since you are indicating that all these items are required, I will assume that there is not much chance of dropping items off the list (at least for now). Given that, you have 2 large tasks at hand - deciding when to do items, and determining how long it will take to do them.
Since you have already conveniently grouped the items by feature, I would start by prioritizing the features. Hopefully this will significantly reduce your working set, and allow you to actually get through it in a reasonable amount of time.
I would prioritize each feature based on its risk. Some things are easy to implement and others are difficult. Since they are all required, do the riskiest features first, when your schedule is more flexible to meet any unanticipated problems. Wait until the end of your cycle, and Murphy's law will strike you down.
Given your small team, I would just send the list of features around and ask everyone to mark it if they consider it a risky or difficult feature to implement. Add up all the marks and you have your "risk assessment", with the highest scoring items getting assigned first.
Alternatively, if you have easy access to your customer, ask them to rate the "risk" associated with each feature (in this case risk refers to the worst-case scenario of not having the feature - if not having something would be annoying, it is not risky. If not having the feature would result in them not using your product, it is high-risk).
Now that you have a priority queue, it is time to estimate. For the initial estimates, I would simply do an order of magnitude estimate for each of the features. Since it sounds as if you have already broken the features up, you should be able to get a decent feel for whether something is going to take hours, days or weeks. From the sounds of it, you are still early in development, so I don't believe there is much point in trying to get an accurate estimate on something that won't be implemented for another month or so.
As you pull items off your queue, have your team provide more accurate estimates by identifying granular tasks that shouldn't take more than a few hours. If you want to refine your order of magnitude estimates, you can progressively provide quick estimates for the remaining tasks based on your up-to-date knowledge of the system.
This should provide you with a fairly accurate short term schedule, and a fuzzier long term schedule that will progressively get more accurate.
Finally, if you are facing a long development cycle, I would recommend you identify certain target goals or dates, and when you meet those goals, sit down and repeat this whole process. I would never go longer than 2 weeks without revisiting these things. New items will get added, others will get overtaken and become obsolete, and others will become higher risk as you better understand the problem. All of this must be taken into account.
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
During our iteration planning, we frequently find ourselves in the same position as this guy - How to estimate a programming task if you have no experience in it
I definitely agree with prototyping before you can give a reasonable estimate. But the same applies to anything that needs a bit of architecture and design - but I'm not that comfortable doing all this outwith the scope of a sprint.
The basic idea is that you identify as many tasks as you can that you're confident of, and estimate these as normal. For those areas that you're unsure of then there should be two 'types' of task identified: Investigation & Implementation.
Investigation tasks are brief descriptions of work that you're just unsure of, for example "Investigate how to bind Control X to data". An estimate is provided for these.
The Implementation task is a traditional rough guess, probably based on the story points assigned, of how long you think it would take to implement the feature.
During the sprint, when the investigation tasks have been completed, the developer should then be at a stage where they have a much better idea what is going on. 'Proper' Tasks can then be identified, which take the place of the Implementation placeholder. In addition, further Investigation tasks may be identified at this stage, and the cycle continues.
In the above example, we start with an Investigation task at 7 hours and an Implementation task estimated at 14. Once the first Investigation has been completed, Tasks 1, 2 and 3 will be identified and estimated with some degree of certainty, where Task 3 is another Investigation task from which Task 4 and 5 will be identified at a later stage. As you can see, the first Implementation estimate had delivery of the feature within 14 hours - but the reality is it took at least 4 + 7 + 3 + 4 + 2 = 20. A third more than the initial estimate.
alt text http://www.duncangunn.me.uk/myweb/images/estimate.png
All thoughts are welcome - my gut instinct is this will fly - am I right or am I the Wrong Brothers?
Cheers!
What we do.
Some features involve new technology. We can't accurately estimate them. Period.
We make up a number. Based on a couple of things. How hard does it "feel"? Can we get by with some kind of "partial" or "just-enough" implementation?
If it's hard, then it's hard. It will be expensive.
If there's a lot of parts, with a kernel of goodness and some bonus stuff layered on, we have a possibility of putting just the kernel into a release, and setting other stuff aside for later. A very few things are "all or nothing" where a partial release isn't possible. In that case, we have to provide enough time for "all", and that gets expensive.
Our standard approach is to get stuff that works, and possibly defer things to a later sprint if we ran of out time because of unexpected complexities.
What you're calling "investigation", we call technical spike sprints. For stuff that's new, we make up estimate number to placate managers who feel it necessary to overplan things. Then we spike the technology. Once it's spiked, we can revise the estimates based on what we now know.
Actually, the implementation of the feature took 27 hours - you forgot the first investigation of 7 hours, so in reality the actual implementation took almost twice as long as the estimate.
There are two ways you can go on this:
Just make the estimate as best you can and potentially experience a blowout in your sprint and a declined project velocity (you should only do this if the feature is both urgent and critical); or
Schedule the investigation for this sprint and leave the implementation for another sprint - without an idea of how long the task will take, the Product Owner does not have enough information to make a decision about in which sprint to schedule it or even whether to do it at all. Only tasks that have been estimated should be included in your sprint.
The first choice means your sprint and project estimates are somewhat arbitrary. The second choice gives much more predictability to your sprints.
In your example, the initial investigation may be scheduled for Sprint 1 but without knowledge of how long the task will take the Product Owner can't decide how to schedule it. If you came back with an estimate of 200 hours the Product Owner may decide not to do that feature at all, or to delay it until Release 2 of the product. The estimate comes in and the Product Owner schedules Task 1, Task 2 and the investigation of Task 3 for Sprint 2. After estimating Task 3, Tasks 4 and 5 can be scheduled in Sprint 3 or later.
Estimating feature usually is complex task. After some time your estimation will become better. But good approach can be that you estimate features with the story points. Story point is abstract value (meaning agreed among the team) that express complexity of the problem.
You should assign the same complexity (same number of story points) to the features of the similar complexity. Then later on it is enough to estimate only smaller set of features (or looking at the historical data) and you should be able to estimate how much time you need.
Features with the similar complexity need similar time effort for implementation.