As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases.
Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.
Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.
Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.
Again, for more details on how to do this read the referenced book.
Big Upfront Estimation is just Big Upfront Design with $$$ attached
You don't, that would go completely against the entire paradigm of agile.
Agile can be about Fixed Costs
What you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.
The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.
Short Sprints with customer feedback and approvals
Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.
Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.
So, you actually shouldn't do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.
Agile doesn't work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.
Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.
Set some very low goals, perhaps only two or three features.
Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.
The client benefits in the following ways:
Lower upfront cost (only a fraction of the total price). If things go tits up there is a limit on their financial exposure (sensible given that most software projects fail).
Have working software within a couple of months that may immediately solve some of their problems
Have working software to provoke thought/conversation about requirements
Client will discover more about what they actually want
Client gets to see how well you work. If they don't like it they can look elsewhere.
"you don't, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates).
You can't expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.
If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).
If the team haven't worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.
Let's suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).
The advantage of this approach is that you can measure the team's actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team's velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.
Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.
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 recently interviewed with a company which has started introducing Scrum for their development cycles. I asked one of the developers how their experience has been, and it sounds like they are completely divested from the planning process. He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Basically, at the start of the last Sprint (or two) he was handed a to-do list. He had to breakdown items into their respective tasks (so they could be worked on over the Sprint), but wasn't involved in any planning activities; I'm skeptical he was allowed much input into how much effort an item might take -- I suspect the architects decided this for the team.
Is this how Scrum should be handled? My current team fully participates in all planning activities, continually adding our input as to how features may be addressed and how much effort they might take. I'm a bit skeptical (and nervous) about a company which simply hands developers a to-do list without asking for their input.
Note: I understand that once a Sprint starts, the list really is a prioritized to-do list. My concern is not having input into the planning process from the start.
If those who are doing the work don't get to give input saying what amount of work can fit into a sprint and let the business decide whats most important and should be scheduled to fit. Its not going to work run away. They are using new trendy agile words but doing the same old things.
(...) He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Obviously, they're still doing command and control and micro-management (the team is not empowered and self-organizing) and they are still using push-based scheduling (they didn't enable pull-scheduling).
Scrum has other characteristics but the above points are more than enough to say that they aren't doing Scrum, regardless of how they name it, they didn't really shift from the outdated waterfall approach (they just did put some lipstick on the pig).
This is a big hint that they're still totally clueless about what Scrum is about, they didn't get it at all. And this is not going to change without some inspection and adaptation, if they even want to change. If you don't have the power to make this happen, run away.
Is this how Scrum should be handled?
No.
I worked at a place that called themselves agile. They had 6-8 month release cycles. Some things came from a backlog, but during the "Requirements Gathering" phase, basically the managers would spend a week or two meeting with various people in the company, and write up a feature list. The first day of each 4 week "iteration", the dev team would all get together and break down everything in a series of meetings. The last day of the iteration was deployment day, where there would be an intrim deployment that nobody outside of the dev team ever saw.
During the 8 month release cycle, the managers would touch base with the stakeholders maybe once or twice in the last two months of the release, at which point the only issues raised in those meetings that had a chance in hell of getting done before release were issues that were bad enough to make the whole effort useless if they were not implemented.
This is not agile, this is a variant on waterfall with a poor choice of ideas and methodologies cherry picked from other methodologies. At the end of the day, it still has all the same problems that waterfall does.
The lesson I took from my employment there is that development methodologies include things for a reason. If you are cherry picking from a methodology without fully understanding it (and by fully understanding, I mean having actually worked with it), there is a high chance that you will not use something that is actually vitally important to the whole thing. For example, in xp, kent beck advocates relying on refactoring later as a way to cut down on up front design. However, the only reason this actually works is that he also advocates TDD and pair programming. If you have a comprehensive test suite and an extra set of eyes there for the whole thing, refactoring is fairly safe. If you just cherry pick the first part and leave those two out, you are essentially cowboy coding.
I am extremely skeptical of shoppes that roll their own methodologies for this reason. There are an absolutely shocking amount of crimes being committed in the name of agile.
Is this how Scrum should be handled?
Definitely not. Scrum strives to increase transparency. By blocking developers from planning activities, they are doing the opposite of what scrum suggests.
You talked about 2 points here:
1. Sprint Planning - The Scrum Team members should be Definitely required here.
2. Backlog Grooming - May or may not be required here. You have to use your resources wisely and with common sense. One team member with strong developer background would be okay here I think.
There is one more type in Scrum:
Release Planning - Some might say developers are not needed here. But as per the Scrum Guide - "Release planning requires estimating and prioritizing the Product Backlog for the Release". Well prioritization can be done by the POs and suggested by the stake holders, but estimating would be most accurate if it is done by someone who is actually going to do the work, so it is a good idea to involve developers here. Again, resources should be used wisely. If it makes sense to not involve all developers and have people rotate turns to estimate, that is not a bad idea.
I suggest follow this structure:
Sprint Planning - part 1 : Estimation and pulling backlogs in Sprint from product backlog (PO, SM and Team are pigs here)
Sprint Planning - part 2 : Tasking, estimating task hours and breaking them down. (SM, and Team are pigs, PO is chicken here unless PO is taking tasks as well)
It is up to the team to figure out, during the sprint planning meeting, how it will turn the selected product backlog into a shippable product functionality. If they are not part of this process then they would not be able to commit.
The answer to your title question is: Developers (team) must participate in planning meetings. Planning meetings are for developers (team).
The good approach is to have two planning meetings at the beginning of each sprint: Planning meeting 1 and Planning meeting 2. In Planning meeting 1 Product owner gives prioritized (and size estimated - size estimation is not done on planning meeting) product backlog to the team and team starts to discuss most prioritized user stories. For each disucssed user story team should be able to collect:
Detailed requirements (for example which fields the input form has to have ...)
Constraints (for example how fast the functionality has to be)
Acceptance tests (verification of results)
UI sketches (for example how should UI flow looks like)
Acceptance criteria (validation from end user - acceptance criteria doesn't have to be real test. It can be something related to "easy to use" etc.)
There should be time boundary for Planning meeting 1. Number of user stories you were able to discuss can correspond to number of user stories you will be able to complete in upcoming sprint. At the end of Planning meeting 1 team must make commitment - say how many of discussed user stories will be done in upcomming sprint. Sprint planning meeting 2 is only for team because team further discusses user stories and breaks them into tasks.
Generally, of course they should. Obviously, it's never realistically possible to the degree that developers would like. However, if sprints are usually "Hair On Fire" type affairs, where the developers get no serious input at all... then at the very LEAST there should be regularly-scheduled "entropy reduction" sprints, where all tasks are selected exclusively by the developers for the purpose of cleaning crap up.
At least some developers need to be there so work can be properly estimated and pipelined.
But not all developers need to be there. All can be there is it makes more sense.
On the other hand, developers need to understand that the business priorities are the priorities, no matter what they think should come next. Everyone has to work together ot make it work.
I'm not so much worried about my input, but about my insight. I recently was involved in a project where I had no knowledge of the project before the plans were handed to me supposedly complete. The nightmare started when I discovered that the process was not completely thought out and the data definitions were not complete. I wound up having to go through the whole process again to get the answers that I required.
The Team can be involved in the planning process without a formal process or meeting. The planning process is really very fluid. At the start, the goal should be to get to starting sprints ASAP. Spending too much time in planning before the first sprint feels very waterfall and is a waste of everyone's time. I, as a team member would feel relieved to not be a part of that, except for the fact that it indicates a dysfunctional nature to the organization. The Team should always be free to voice ideas on an ongoing basis (since that's when the real planning happens). But, 2 things you mentioned concern me most.
First, the Team should be the only ones to determine how many backlog items they can do this sprint. They certainly would be involved in estimating the effort. That's a big problem.
Second, the Team does not sound like they have access to the product owner (maybe there ins't even one here). Even if the team has not been involved in the "planning" thus far, surely if I were talking to the product owner in the planning meeting, or had access to them at other times, I would voice suggestions over time.
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
Summary
We are start up and we provide software development services. We develop windows, web, services and mobile applications. We were aware of agile and we are scrum certified developers . We do user story based estimation and task planning. No issues.
Issue
We are approached by many small customers. Customers says very high level features or few words about the concept of their dream project. They asks for Effort Estimation and Cost Estimation. Mostly they are interested in Cost.
For each customer we did create the user stories and estimated the user stories and based on story points, we estimated the effort in days and we convert the days to the cost based on hourly rate. We involve the team of 3 or 4 people and get the estimation done. We spend at least 20 to 30 hours of team total time for estimation. (Team of 4 discussing for 5-6 hours)
The problem is that many customers would never turn back. We do not want to spend 20-30 hours of team effort. We don't want to use the exact user story estimation that we follow for contract signed project.
Question
What could be done in order to provide approximate estimate for small customers with small business?
I don't know there is a solution, other than to find 'better' customers. It sounds like you're doing it right to me. Non-technical customers often want you to spend 30min on the phone with them and then give them a price for the whole thing, so it's good you take the time over it properly. However then you often waste your time.
Maybe you need to say 'no' to customers who you don't think are serious. Or charge for the time spent doing highly skilled estimation work.
By 'better' customers I mean bigger companies, who are more experienced with software (and also probably have bigger budgets). The downside is more paperwork - you are much more 'free' dealing with small firms but also more at risk.
You don't have to stick to a fixed-price contract, for requirements that are vague you should look at doing time and materials.
Basically you need to spread the risk of the cost of overrun between you and the client.
A hybrid option might be to do some T&M proof of concept work then fixed price for the rest when you understand it better.
Alternatively, if you client has a pot of money then use your agile strengths to work with the customer to incrementally deliver functionality until they run out of money.
"We do not want to spend 20-30 hours of team effort."
Then don't.
If your estimating method is too costly, stop doing it.
"Customers ... are interested in Cost."
Then get them a cost more quickly. Do less work. Don't use a team of 3-4 for 20-30 hours. Have one person do it quickly.
One person can create a spreadsheet with stories, story points, priority, hours and cost. That's the project backlog for Scrum. That's the estimate. That's enough to start a conversation. It's not a fixed-price estimate.
A simple spreadsheet with stories, story points, price and priority is all you need. Then you can work with the customer to adjust priorities to determine how many of those stories they can actually afford to buy.
If they want a fixed price, you simply need to review each story summary to see if the points are right. You already have the spreadsheet, and the priorities, and the formula to compute price.
The unfortunate short answer is you are going to have to significantly reduce your estimation costs. The only way to do that is to reduce the number of people to one and use a formula approach.
Take a best guess. Put reasonable assumptions in the contract. If you do a decent job, some will be a little high, some will be a little low and it will average out in the end. If you are off by too much, track changes within the project and charge for them. The key will be in the assumptions placed in the contract, usually in the form of a statement of work.
This is normal business, from small projects to enterprise projects. Just a matter of scale. It doesn't have to be done this way, but it often is.
This reminds me of the challenge between time, money, people and overall quality. Some people can see this easily and others may struggle with the idea. Part of the key point here is to understand is what kind of expectations do you want to set and what kind of leeway do you have with the customer. For example, how are bugs in the software or overall support factored into the project.
You may want to consider how much work do you want to do upfront and on what kind of scale are you spending the 20-30 hours estimating a project. Comparing the cost of that much time spent generating an estimate, which # $40/hour is $800-1,200 by the way, to what the revenue from the project would be is something to consider. If the entire project is $400, then was it worth spending twice that coming up with an estimate? On the flip side, for million dollar projects, it may well make sense to spend that kind of money.
My suggestion would be to see if there is a cookie-cutter approach that could be taken for their projects so that there isn't as much variability to the projects if that is possible.
Theres two sides of estimation, first creating the initial 'ball park' figure this should be done relatively quickly, it should be emphasised its a ball park figure and its the start of your conversation with your customer, its not a contract. Second you do your more detailed team based estimation.
This is how this consulting company does it - Ball Park Estimating
Create a template spreadsheet with times and costs for typical pieces of work, look at the initial requirement and update your template. Start the conversation with this is the ball park but we will need to work together to confirm a final price and get a more accurate estimate. This more accurate estimation process will take x hours and cost x dollars.
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 8 years ago.
Improve this question
How do you charge your customer in a project using agile methodology?
Per hour? Then a great deal of trust has to been established before the project.
Per iteration? There's gonna be a lot of budget decisions, which can take time.
Per project? How can you do that when you don't know the scope? The very essence of agile is to not write a big upfront design/specification.
You charge your customer on the base of the terms defined by your contract that will be slightly different from a traditional fixed bid contract. Let's call that an Agile contract.
Some options are discussed by Alistair Cockburn in Agile contracts.
Another great resource is 10 Contracts for your next Agile Software Project by Peter Stevens.
Mary Poppendieck also has great material on this topic. See agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. More here.
Short answer is, you won't. There are a few services companies that are making headway doing it, but it is a difficult path. Your ability to sell the methodology and convince the customer you can deliver will be high.
Customers don't want to risk paying for a solution that will never be delivered.
Typical approaches to this problem are to put "will not exceed" cost. However, if you can't control scope, you are the one taking all of the risk.
In short, you are looking for customers that would have signed up for T&M (time and materials) contracts before Agile became the latest fad (I'm part of that fad, but it is just one in a long line of development processes. Aspects of it will continue to grow and some permutation of it will have a different name in a few years).
If your customer has already bought into the use of an agile methodology, then you have a reasonable framework for negotiating price per iteration. For example, you know:
How long the iteration will be.
How many people will be committed to work on the iteration (and their rates).
An approximate scope of work.
A process for delivery and acceptance.
That's a lot more evidence on which to base pricing decisions than is available for most fixed price contracts.
If the agile methodology is purely an internal development process that doesn't involve the customer, then it's unlikely to have much effect on the pricing negotiation between the supplier and the customer. There is an argument that says that a process that doesn't involve the customer in setting scope and expectations at least once per iteration isn't agile at all.
Regarding Mark's comment, there is a very common pricing model based around fixed price contracts with loosely defined scope and optimistic schedules. A common outcome is that both supplier and customer find that their initial optimism was misplaced. Both end up negotiating from weak positions over the things that really matter to them, and both end up unhappy.
Some of the techniques that work well in managing this type of contract are very similar to those used in managing agile contracts (frequent delivery, horse-trading on scope, priorities & price, frank communication, ...) the main difference is that these aren't built into the original agreement, and the contract may not be flexible enough to accommodate all of them.
My 2c as a non-agile practitioner...in a quest to know more...
If you are doing a specific project for a customer, you will need to know the scope of the project to provide a cost and a timescale. The cost of producing this scope of work is more often than not part of the discovery of the project, you either take a hit on this to get the work or charge for this (explicitly or implicitly) In this case, a project cost can be worked out and agreed. Im this case the project is usually broken up into various stages.
Although agile may be iterative and not require a full specification; a goal, at least is certainly required. There must be some form of basic specification/requirement. It may be that you need to break the project up into smaller goals and apply costs accordingly.
The iterations I suspect are more to do with the development methodoology, ie to achieve the goals?
If there is not enough specification to produce a definitively accurate cost, I would say that a "estimate" should be given but work should be charged at an hourly rate as I would assume that there would be greater changes in the decisions made on the project over each iteration.
I've seen it work well when approached in 2 phases:
Phase 1) Inception (timeboxed)
A timeboxed inception period with the client to scope the project. (A one month intense inception for a project estimated to last a year is about right.)
Outputs to this phase are a full backlog of sized user stories, an estimation of flow rate per dev pair, and parameters to estimate project costs based on the number of developers and overheads of having larger teams.
The inception provides a useful budget estimation that can be tracked throughout phase 2, a clear shared vision for both client and supplier, plus the option for either side to walk away. This isn't upfront design, the stories have just enough detail for a lead dev / tester to assign relative sizes.
Phase 2) Delivery (time and materials)
A delivery contract based on time and materials, with budget estimates based on the outputs from the inception phase. The trust built up in phase 1 is vital to making this work. Because phase 1 delivered relative sizing of the entire backlog, by regularly measuring actual flow it is possible to easily and frequently report projected flow rate for the rest of the backlog with increasingly accurate estimates of budget and delivery date. The supplier should be contracted to report these stats at least every 2 weeks, with the option for the client to walk away at any point.
By paying for time and materials, the client is free to change the scope and proirity of the backlog, and is therefore in control of the budget. They are encoraged to prioritise their highest priority / highest risk stories first, and by allowing them to walk away whenever they like they should experience a positive return on investment at all times.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We have been trying Scrum but for a while now and are trying to formalize it within as our own version of Agile Application Development. Here's how our current process works. There are two main drawbacks to it as it stands right now. Wanted to get input on whether you have a similar approach and if the community has any practical tips for the impediments we currently have.
Scrum team = 4 Developers, 2 QA, 1 Tech Writer, 1 PO(PM), 1 Scrum Master (Engg Dir)
Release = 3 Sprints
Sprint = 2 weeks
PO and customers create product backlog of user stories and related acceptance criteria.
1 week Sprint planning at the start of each iteration
Day 1# Estimate the Sprint backlog and agree on priority
Day 2-5# Scrum team discuss stories and work on the details of each story in the Sprint backlog (get the details on the story, process flows if any, identify UE guidelines to apply, details for UI items/fields/widgets and their behavior if anything specific is required, understand acceptance criteria and create tests)
2 week Sprint with 15 min daily scrum
Repeat 3 week cycle
The two major drawbacks we're having in this are:
The details that are discussed in the spring planning week are not captured effectively and get noted on a wiki. Since there is no standard format for capturing such details in Scrum, often time is wasted in daily scrum or subsequent meetings are required to further understand story details. Whats the best way of capturing story details for a functionally fairly complex product in sprint planning? Most of the issues seem to be around UI and developers inability to decide how screens/fields should be laid out without detailed mocks.
How do you anticipate critical showstopper bugs that come back from customers when team is in a sprint cycle. Currently the Dev folks have to be pulled away into supporting these Red Account issues that crop up thus disrupting the sprint.
Any inputs on how we can improve this?
There is no "standard" Agile plan. Plans aren't important.. planning is. What i mean by that is adapt your plan regularly to reflect ground realities. Formulating a plan, having it blessed by the powers to be and then strapping on developers hasn't worked traditionally.
Sprint planning shouldn't go over a day if I'm not mistaken. One of the key ideas of scrum is that you don't spend too much time planning. If they do, stop and reconvene when you have better clarity.. dont trudge on.
Get prioritized set of stories from customer ~3 hrs
developers huddle to estimate ~3 hrs
show estimates and let customers change their bucket to reflect business needs (within sprint quota) ~rem time.
Documenting decisions:
Get a good scribe? Someone who can type away as fast as 4 people talk.. get the core statements/decisions in a high-visibility area like a chart.. or a wiki.. whatever works for you
UX Study:
Try to pipeline UX work. Make sure the UX people have already worked UI Details,Mock screens, workflows, etc. by the time the devs get to it. UX is working on stories for Iteration n+1 when the devs are working on iteration n. A bit difficult but can be done if UX is causing a lot of "thrashing" for you.
Bug-Duty:
One approach is to make all bugs as regular backlog items for the next iteration. Get Customer buy-in on which ones need to go in during sprint planning.
If that is not feasible, Trend bug-inflows, rate of fixing and plan for it. Keep x days marked away for the fix-on-demand devs dedicated for these requests.
Scope for improvement:
You need a dedicated person in the "customer" role (or coach/BA who can front for the customer) that the developers can get in touch with on a real-time basis. Daily scrum meetings should be timeboxed to 30 mins and shouldn't include story "clarifications". Stick to the 3 questions - What did you do yesterday? What are you doing today? Any obstacles you need help with?
The dev or sub-team in charge of a specific story should work with the Customer/Front in case of doubts while they are working on the specific task. They are responsible for extracting out the details as part of the development effort. They can request for help from other devs who have worked in related areas too if that helps. Work together with the customer to stay on the right track.
HTH
Yep. I noted that nowhere in your process were the developers listening / talking to the actual end users. This is a recipe for failure. You cannot expect your "PO" to catch all the nuances that the actual users will express.
Developers must talk to the end users. The PO should be there as well, to document what was discovered. This is the biggest problem I see in most development projects, separation of developers from users.
Why are you sprint planning meetings a week long? The goal of sprint planning is to get just enough detail to feel comfortable as a team with the features you can get done and commit to doing them. This usually takes less than a day (~4 hours). The actual implementation details are discovered just in time by the devs during the sprint. That is why it is so important that they have access to the PO and the users. If you are asking where to capture the details, then you are designing to much in the planning meeting. The details should go directly into code during the sprint as they are worked out.
What would be a showstopper? The PO sees the progress at the end of each sprint (2 weeks) and then decides if the business value is enough to warrant a release. If there were any critical issues then the PO would probably not release that sprint. Hopefully you can get your PO and maybe users to look at the product on a daily basis as features are completed and thus reduce the probability of issues at the end of a sprint.