When you’re trying to get started on your first agile/scrum project, it’s easy to find arguments about why it’s a good approach. But it’s a lot harder to find clear, step-by-step explanations of the tools and processes you need to succeed. I’m trying to fill that gap by answering the question: How do you estimate story points on an agile/scrum project? Read more on How to Estimate an Agile/Scrum Story Backlog with Points…
We work with clients to define custom software proposals and create a responsible budget. In this task, we’re always going to be in a position where there are unknowns. For example, a project may need to integrate with a third party service we’ve never used before. We have to assume the service works as advertised. We really won’t know until we do some additional research and start working with the service. Read more on Making Smart Assumptions in a Project Budget…
Atomic Object builds custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.
As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.
A Fixed Price strategy locks in the total price of the project upfront.
Static Variables: Scope, Cost
Flexible Variable: Quality
Assumption: The estimate and plan are correct and will not need to be changed.
Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.
In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price. Read more on Fixed Price vs. Time & Materials vs. FBSC (Fixed-Budget, Scope-Controlled)…
I’ve been at Atomic Object for approximately 8 years, and during that time I’ve had the opportunity and the challenge of managing relatively large software projects. I’ve learned quite a bit from fellow Atoms and picked up a few tricks of my own throughout the years. One of the best practices I’ve picked up is keeping a well-organized and properly-categorized budget.
Software projects are generally given an overall budget that a team can work against. However, the realities are that a budget can be made up of a number of different components — some of which have nothing to do with actively creating features and are instead meant to be used for upfront processes (Kickoff and RDP Phase), customer communication, project management, technical documentation, etc. Depending on the overall complexity of your project, you may have one or two of these categories or all of them. Read more on Breaking Your Budget into Categories…
Estimating a new project is hard and time consuming. Why? Because when you start a new project, you are at the point of maximum ignorance. In most cases there is a solid idea, but the required functionality is ambiguous.
The business is depending on you — the engineering team — to identify a high-level timeline.
I estimate a lot of projects like this every year. Here are a things I do to cope with that ignorance and ambiguity.
1. Select the Right Magnitude
Begin by deciding a uniform level of precision for your estimates. If you think the project is going to take years, then your estimates should be in weeks. If you are guessing months, your estimates should be in days. And if you think the project is going to take weeks, you should estimate in hours. Read more on 5 Tips for Estimating at the Point of Maximum Ignorance…
When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
Buying custom software design and development services, especially for the first time, can be scary. There is clearly a knowledge imbalance between you and your service provider. They (hopefully) understand the effort required to successfully build your product, and you don’t. This puts you at risk of being taken advantage of.
I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:
Breaking things down by value, not by task
Thinking in terms of “size” (not time)
I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.