Discovery & Definition

One of the first phases we go through in a project is what we refer to in the engineering space as Discovery & Definition.

The goal of this phase is to get a decent understanding of what the project should be and what the initial scope of the project should be.

This is generally done through a series of meetings between the stake holders and Uptech Studio Product, Engineering, and Design representatives. This is where we combine what we know the client wants with our knowledge and expertise to eventually result in what we are actually going to build for them. This is also often where we pose questions or push back on the client to identify if ideas have been vetted and tested to make sure that their money will be well invested.

Once we have these meetings and have come to a conclusion as to what the product should be and what our initial scope will be we move onto the next phase, Estimations.

Estimations

Prior to this Product is responsible for outlining User Stories based on the learnings from the Discovery & Definition phase.

Here at Uptech Studio we aren't big believers in estimates. In fact we generally don't believe or trust in estimates. But our clients need to be able to budget and plan, not down to a date or week even. But they need to have an understand of relatively large time range and budget range to find out if they can even afford to pay us and if the timeline will work for their business need.

So we use this as an opportunity to have the Tech Lead start to think through all the stories and what is going to be involved with them and estimate the story at the scale of indivdual developer worker days. This is generally done in Airtable.

We then sum up all the working days and add a multiplier based on confidence and unknows using around 1.5 and 2 to account for the fact that estimates are generally over optimistic.

These numbers can then be used to compute roughly time range and cost range based on these estimates.

Project Planning

The Project Planning phase is where we take the knowledge we gained around the project scope and start planning out the high level technical details around the work. The goal of this phase is to do an initial relatively high level of planning to start to breaking down the technical problem space and identify unknowns, concerns, and blockers. This is generally achieved with the following artifacts of this process which are the responsibility of the Tech Lead to produce.

• Systems Architecture
• Project Detailed Spec
• Defining Unknowns

Systems Architecture

The first artifact for this phase is a Systems Level Architecture diagram that the Tech Lead is responsible for putting together. The goal of this is to simply start the conversation and discussion around all the entities in play at a system level and how they are going to interact with eachother. Over time this continues to be updated and used as a conversation piece to discuss and review systems level interactions.

Project Detailed Spec

The Project Detailed Spec is a document that the Tech Lead is again responsible for. This document defines the project scope and goals for review as well as the Systems Architecture to provide context. Beyond that it is a vehicle to explore the next tier down of technical problem solving. This could be how the various components would be interacting with each other. Is it done via GraphQL, REST, etc? What are some rough ideas of what the key functional data is needed to be passed between these system components. These types of questions and thinking. It isn't to formalize 100% exactly what the payloads will look like. It is just to get an idea and an understanding to gain more confidence.

The process of the Tech Lead walking through, planning this out and documenting it helps them start to think through all of the components and how they will interact to accomplish the defined goals. This also helps identify up front major unknowns, concerns, and blockers very early on in the project so that those things can be focused on from the get go.

Project Design Review

Once the Project Detailed Spec is produced the Tech Lead then schedules a Project Design Review internal to Uptech Studio. This meeting enables a round of review and feedback on the architecture and design that is documented in the Project Detailed Spec. This generally should have a representative from Product, Design, and Engineering. The people at this point aren't from your Squad. As a Tech Lead you can choose to do Squad internal rounds of feedback with the engineers prior to this meeting.

Project Kick-off

Once the Tech Lead has held the Project Design Review, gotten feedback, and integrated that feedback into their Systems Level Architecture diagram and Project Detailed Spec they then schedule a Project Kick-off meeting with their Squad. This involves all members of the Squad and provides in opportunity to go over everything covered in the Detailed Spec from the project Goals down to how the various components will be interacting and with what data.

The purpose of this meeting is for all the members to get comfortable with all of this and voice any concerns, suggestions, etc.

Upfront Planning?

I thought Uptech Studio did Agile. We do! Nothing in Agile says that you shouldn't do up front planning. Agile is all about iterating and getting feedback throughout the process and adjusting to that feedback. But nothing in it says you shouldn't think about how you would build or implement something. Our experience over the years has informed our opinion that doing a small amount of up front planning like this is often a game changer in terms of the success of a project.

Design Review

This document describes how and when a software design review should take place.

What is it?

A design review is an opportunity to get feedback on your application design prior to spending a lot of time working on the implementation.

Even if you love to do emergent design using TDD, when projects are large and complex, some upfront design is necessary. It's hard to identify all the components that exist and what their interactions are with existing systems without taking some time to think through it. It's also really helpful so you can break down a larger project into smaller components.

As a general rule of thumb if a project is going to take more than a week to develop, then it probably should have a design review. Smaller projects will have real quick meetings, whereas larger projects will probably take some serious brain power.

When does it take place?

A design review should happen after the requirements have been documented and delivered to the implementation team, but before any code has been written.

Ideally the product owner will have a kickoff meeting with the team to go over this new feature and how it should work. After that, the engineers can review the requirements in detail and start coming up with an implementation plan.

Within a few days of the kickoff meeting, the engineers should have a design review meeting to go over the plan.

Who should be part of it?

The technical lead of the project is responsible for scheduling time to plan and document the proposed design. They are also responsible for scheduling the review meeting and making sure they have proper representation at the meeting.

A design review should have the following people:

• Technical Lead
• Backend Representative
• Front-end Representative
• Infrastructure Representative
• QA Representative (Ideally the person that will be testing this feature)

Including members from other teams helps to address any concerns they may have earlier in the process as opposed to later when it's more expensive to change.

How does the meeting run?

During the meeting, the technical lead on the project should review the feature being implemented at a high level so everyone in the room understands what the business objectives are. After that, they should walk through a document detailing the implementation plan.

The document should include the following:

• A high level description
• A diagram of the different systems/components
• A sequence diagram indicating interactions between components/systems
• Interface specifications (REST API, Message Formats, etc.)
• Callout for new Infrastructure components
• Rollout plan - call out any sequencing required

Why should we do this?

Because we want to build awesome products with the highest standards in mind and avoid making desicions that may bite us in the future.

Roadmapping

The Roadmapping phase is where the Tech Lead and the Product representative collaborate together to define a Roadmap of Milestones for the project. During this process we take a number of things into account.

• technical dependencies & constraints
• best way to show client progress without fabricating Demos or doing Demo Driven Development.
• make sure we can internally deliver testable versions to stakeholders

This is done in Jira using the Roadmap feature. The high level Milestones are broken out and defined & prioritized first based on the criteria above in collaboration with Product.

The Product person then takes the User Stories from the Estimations phase, cleans them up (adding any new ones, adding details to stories, etc.), and organizes them into the roadmapped milestones.

Milestone Planning

The Milestone Planning process is basically the same process that we do in terms of Project Planning. The main difference is that we are planning within the scope of a defined Milestone. This process is again driven by the Tech Lead. It can be thought of in the following sections.

Scoped Systems Architecture Diagram

When doing Milestone Planning you are scoping your thought process and in turn your created artifacts to a particular milestone. Therefore, you are creating a System Architecture Diagram that only focuses on the needs for this particular milestone. This is useful again to provide context but also useful to remove the noise of everything outside of the scope of this Milestone.

Application Architecture

The Application Architecture is where you start to visually layout how your team is going to build an application that will meet the needs of the goals. This again is about components, how data flows through them, and what components handle different types of processing.

Scoped Protocol Specifications

These protocol specifications again aren't inteded to be 100% accurate in terms of every piece of data. It is intended to be a tool to make the Tech Lead think through the core data that needs to be exchanged via this different channels and what those protocols would look like.

Infrastructure Diagram (depends on need)

Infrastructucture Diagrams aren't always necessary. Basically if there is something complex and abnormal necessary in the infrastructure then we should create an infrastructure diagram. The other use case might be that a client is explicitly requesting or pushing for an Infrastructure Diagram.

Sequence Diagram (depends on need)

A Sequence Diagram is again dependent. If you are in a situation where you need to clearly define and communicate about complex interactions between system level or software level components a Sequence Diagram is the tool for you.

Flow Chart (depends on need)

Flow Charts again aren't required but are super useful when you have some complex logic that needs to be planned out and thought out.

Detailed Design Spec

The Tech Lead then puts together a Detailed Design Spec similar to the concept and structure of the Project Design Spec from before except scoped down to the concerns of this one milestone.

Unknowns

Part of this process is identifying unknowns. We use these unknowns to guide us by effectively being blockers that need to be figured out to complete this milestone. We need to try and answer these unknowns as much as possible prior to the design review. However, some unknowns might be dependent on getting feedback from 3rd party vendors, etc. We should start those conversations with product and the 3rd party vendor ASAP, prior to the design review.

This list of unknowns should be a working list of blockers that should get formalized as tickets and prioritized generally to be figured out ASAP. There are sometimes cases where you might want to not prioritize resolving one of these unknowns until later. This should be vetted with the project's principal engineer.

Design Review

Once completed the Tech Lead schedules a design review (same process as before) except this time it happens within the Squad. If the Squad feels they need external imput from people outside the Squad they are welcome to invite other people.

Kick-off Meeting

Once the Design Review process is complete. The Tech Lead schedules a kick-off meeting for the Squad. This has the same purpose as before. It is to get everyone comfortable with everything and provide a venue for people to raise concerns, ask questions, etc.

Task Breakout

One thing that different Squads tend to do differently is task breakout. Some Squads have an extra step here after the kick-off meeting where they schedule a meeting with Squad Product representative and the Engineers on the Squad and go through the tickets in the Milestone and breakout sub-tasks for each of the stories.

Other Squads don't do this meeting and instead leave the task breakout to the Engineer that grabs the story. We don't have strong opinions on this. It is really whatever the Squad is comfortable with. The key is that our Squads are constantly self evaluating so if there is a problem in this area they can quickly adjust.

Milestone Estimations

Despite our dislike for estimates due to their inaccurate nature we still do them in some form because the reality of the situation is that we need to know relatively early in the process if we are going to be able to hit a timeline or not. Obviously we can't know this 100% because as we have stated estimates are very inaccurate. However, they can gives us a pulse to know if we think we are significantly going to miss a timeline. This is crucial as that pulse is what instigates pruning of non-crucial features and setting expectations appropriately with the client.

To facilitate this we of course start with the initial estimates from the Discovery & Definition phase. However, things have likely changed since that time and the developers haven't thought about the complexities of each of those milestones.

To facilitate this when a Journey is reviewed by product with the associated dev team. The dev team goes back through the milestones of that Journey and puts together estimates based on the following thinking.

Origination of Thinking

Historically we have focused on the concepts of Complexity and Effort while putting together estimates and it was only our Milestone Planning that thought about unknowns and risk.

However, relatively recently Theo dropped a video where he broke down what he has thought of for a system for estimates. It is very much in alignment with our current approach as it takes Complexity and Effort into consideration. However, beyond that it takes into account Risk and goes through the reasons for estimating in a more analytical fashion. Therefore, we have effectively adopted his approach with some small tweaks.

We also differ from his approach in that after thinking through these characteristics we then estimate how long things will take (in developer days) using these characteristics guidence. This is critical for us to understand how we are making progress in terms of our estimates so that we can make adjustments and manage client expectations appropriately.

Theo - Why Are Estimations So Hard??? PLANNING TASKS AS AN ENGINEER

Why we estimate?

We do estimates at the epic level for the following reasons.

• Identify who should do it
• Identify when it should be done
• Identify low performers
• Bring risk to the forefront so that it can be addressed/mitigated
• Prioritize based one ^
• Identify how long it will take (this will be wrong, but hopefully taking the following system into account will help make it less wrong)

The Breakdown

Our estimation system is broken down into 3 categories, Complexity, Effort, and Risk.

• Complexity (1-10) - How "hard" is this thing to do?
• Effort (1-10) - How much work does it take?
• Risk (1-10) - What are the chances that Complexity or Effort is off?

Getting Started

When first getting a team started thinking in this way we have found that it is useful to often go down to the story level and document the Complexity, Effort, and Risk as it ends up being a forcing function to think about the complexities and risk. Then go back up to the milestone and produce the milestones Complexity, Effort, and Risk. Then you can look at the stories overall and validate that your estmiate for the milestone makes sense.

Once the devs start to get the feeling for thinking about Complexity, Effort, and Risk this process goes really quickly.

Breaking out Research Tasks

As we go through this process we are often running into Risks and most of the time you need to do some further research to understand and mitigate the risk. This is the perfect time to break those tasks out.

You can also see by doing so how breaking the research task out helps you to think about and adjust the characteristics for the story and its associated research task.

Example

The following are a couple examples from the video referenced above with the addition of the developer days estimates.

Display voice levels in pre-call view

• Complexity: 4/10
• Effort: 2/10
• Risk: 6/10
• Estimate: 4 dev days

To reduce the risk of this task we could create a research task to figure out one of the bigger pieces of risk. For example.

Identify how to get voice levels from 3p SDK

• Complexity: 2/10
• Effort: 2/10
• Risk: 4/10
• Estimate: 1 dev day