Agile Contracting: Discovery, Fixed Budget, Variable Scope By
n the article “Agile for Fixed Bid Projects“ by Shrikant Vashishtha , he discussed about committing fixed number of story points and swapping any additional scope with existing backlog. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and client/product team understands this agile approach. Still, fixing size, undermines one major aspect of an agile team – “applying learning back into the project”. Development teams while doing size estimation give higher points where there are uncertainties and risks. Known unknowns, new technology, unclear requirements etc. are few reasons for providing higher story points. As project progresses, team s get m ore knowledgeable (both technology and business) and hence some tasks now look smaller than before.
Recently, a team estimated the backlog to be around 250 points for beta release. But as soon as they finished two sprints team realized that some of the stories in the backlog are of lesser size than estimated. Hence team w ent ahead and reestimated some of them which brought backlog size to 220+ points. Here, if team had a fixed size contract of 250 points, then they would be discouraged from saying that rest of the backlog is lesser than earlier. This refutes one of the values of a scrum team – Honesty and transparency. By doing so, team here built great level of trust with the client. So then how do we solve this agile contract thing? How do we execute in an agile manner when there is less trust between product (read client in services) and engineering? It is tough for new client or in-fact even clients with decent agile knowledge to sign a contract based on story points. Many of them feel it is random number which can be gamed. We all know that only language every business owner understands is MONEY. How Feedback: email@example.com
about then fixing a budget and keeping scope (size) variable? So this m eans you have tentative understanding of how many points you can approximately achieve but it can change keeping budget fixed. Budget is fixed by fixing team capacity which is the biggest variable. This means, we have to tweak the approach to team based staffing model. A quick list of steps to arrive at the budget:
1. Define the product backlog 2. Estimate the size (I prefer one sizing to arrive at
quick estimates over poker at project start or during proposal stage). 3. Identify a team(Dev, QA, Designer, BA etc.) and team size – team based staffing model 4. Forecast a velocity by team mocking sprint execution(do at-least for first 2 sprints) 5. Plan the number of sprints needed with this average velocity to meet the product backlog size. With this fixed team size and with number of sprints, you can calculate the budget Example: So a backlog size of 250 points, with average forecasted velocity from step 4 coming to say 25 points, then we need 10 sprints with a team size of 7 people assuming a fixed sprint duration, say, 2 weeks. Now fix a budget as per your billing rate and propose this budget to the client. Team and client can now work within this budget to deliver high priority features. I prefer now or later prioritization approach here. It is a major mind-set shift for clients to move away from Fixed price, Fixed scope and almost fixed time kind of engagements where only variable was quality Throwing a random number on a long requirements document in short time, eventually leads to lot of overtime, low morale, scope misunderstanding and what not. These kind of engagements call for sweat and blood project management and execution. Projects starts to bleed in such contracts. Companies
who value this are saying NO to those clients where you have to throw a fixed number on a 200 page requirements document in short time. This is the big-
gest bane of the services sector – committing numbers when you know least about the project. Foot-in-the-door thinking is other reason why many companies can’t say NO the clients even if they know it is risky to provide numbers so early. Can we do discovery first? Go for discovery workshop rather than comSynergy Oct 2015, Page 16