Scoping Workshop - Plan and Tips for Scope Session in Software Projects
Scoping workshop provides an excellent opportunity to clarify the needs of the project, disclose areas that haven't been considered earlier...
In this article, you’ll learn about:
There are plenty of reasons, but let’s focus on a selected few:
There are several types of cost estimations in software project management.
At Asper Brothers, we use ballpark estimates, providing a high-level overview of the project costs. We break the project down into phases, starting with the „Discovery/Analysis/Design/Scoping” phase. Only then do we prepare a much more accurate – and detailed – final budget with our client.
There are several popular cost estimation techniques, but we prefer to mix some of their elements into our own individual approach.
Let’s dive in a little deeper into how we actually do it.
In our ballpark estimates for software projects, we focus on these elements:
We don’t typically include the resources needed to complete a project or its duration in a ballpark estimate. We go into that in our detailed proposal. We provide clients with detailed comments explaining how costs work in a project – to make sure we’re all on the same page and there are no misunderstandings at any stage of the project.
Let’s look at the whole process of project analysis and estimations at Asper Brothers – from the moment we get an RFP to the kick-off of the first development sprint.
1. We gather as much information from the client as possible. This might include a high-level idea for the product, its business goals, any details of the existing software architecture and infrastructure, wireframes and mockups, and user journeys – anything that will help our team understand the needs and requirements for the project.
2. We get a team together, which depending on the scope of work we have to analyze, might consist of:
The team members look at all the project materials on their own. Then, we host a quick meeting to exchange questions and doubts and make sure everyone’s on the same page.
If we have questions or concerns, we create a shared file and send it to the client or product owner. When we have the answers, we usually meet again to discuss them and hop on a call with the client. We define the scope of the project and collect all of the requirements.
3. We create a high-level architecture and infrastructure design and describe the tech stack we’ll use.
We define the team’s desired breakdown and create a high-level agile timetable of things we need to do before the first development sprint. Then we break down the scope of work into detailed elements.
4. We meet for an estimation session to estimate the time needed for each of the elements. Estimations can be tricky, so even after we’ve completed all the points above, we might still have some questions and doubts at this stage. If we do, we leave those elements blank and move on. Then we get in touch with the client to clarify them.
This is an important refinement session leading to a more accurate estimate.
5. There’s a lot of uncertainty in software development, and discussions during the estimation process can get heated. So we define an Inaccuracy Risk Level score for each element. The score can be low, average, high, of very high.
Low risk means the estimates are almost certainly accurate. A high or very high score means that there’s a chance we’ll exceed the estimates, and we can’t specify by how much. (Since it’s a “risk”, this might not happen in the end, but we want to be prepared ahead of time.)
6. As soon as we complete estimating all of the elements, the team goes through the estimates one more time and refines them. After reviewing our proposal, estimate, requirements, and risks with the client, we make final adjustments.
7. We make sure the backlog in Jira is up to date with what we finally agreed on. We develop user stories and host a backlog refinement session.
8. The ballpark estimate is based on hours. Apart from it, we host a Scrum Poker session during which the development team awards story points to each user story.
9. Finally, we can kick off the first development sprint.
Overshooting (and undershooting) is really easy in the estimation process. And it can either cost you a client or lower your profits (and get people frustrated).
So, if you don’t want to miss the mark, here are a few of the strategies we use – and recommend – to make sure we stay on track.
There’s a bunch of online tools you can use to create cost estimates. We like to keep things simple, so we usually use:
Most importantly, we rely on our team’s knowledge and experience – they’re key to an accurate software project estimate.
Scoping workshop provides an excellent opportunity to clarify the needs of the project, disclose areas that haven't been considered earlier...
If you’re looking to outsource software development, there are essentially two pricing models you’ll come across in most software...
If you want to build software with an external company and think a request for a proposal is a thing of...