Introduction to Work Intake – Part 3
Welcome back to the final exciting chapter in our three-part series on Work Intake. Throughout the past two blogs, we’ve used dialogue with our requestor to help form a more thorough understanding of the true “ask” from us. In Part 1, we used an anchor chart to gather preliminary details from the original brief description. In Part 2, we reviewed the workflow details along with considerations for parameters and outcomes.
Before diving into today’s section, let’s quickly review what we’ve gathered thus far from the three different use cases, as we’ll be referencing them in the next section.
New infrastructure at a remote branch location
- Who: Remote branch users
- What: Site build-out of a firewall, switch, and wireless access point
- When: October 31st
- Where: Burbank remote location
- Why: Company is expanding to meet customer demand.
- How: Physical build-out of new location to include placement in SoT (Source of Truth) and monitoring
- New or Existing: New
- Frequency: One-time
- Steps: 51 to 99
- People: 4 to 10 People
- Approvals: Yes, 3 to 5
- Dependencies: Yes, 3 to 5
- Locations & Environments: Internal production
- Methods & Access: SSH-CLI with a User account
- Change Management: Higher risk change: impacts production with new routing changes
- Business Value: New location provides opportunities to reach new customers for better growth and market share.
- Acceptance Criteria: When onsite staff are able to use the new equipment to access the main Data Centers.
Migrating from SNMPv2 to v3
- Who: Monitoring Team
- What: Remediate the 100+ network devices
- When: Risk closure by November 1st per Security Team
- Where: All locations (35 sites)
- Why: New security standard due to an internal audit
- How: Device configurations moved to the new standard
- New or Existing: Existing
- Frequency: One-time
- Steps: 4 to 10
- People: 4 to 10 People
- Approvals: Yes, 3 to 5
- Dependencies: Yes, 1 to 2
- Locations & Environments: Internal production
- Methods & Access: SSH-CLI with a User account
- Change Management: Involves a couple of teams which would require a regular weekend change request
- Business Value: Security & audit compliance, able to close out the Risk item
- Acceptance Criteria: When the Security team is able to resolve the audit item.
Create automation for the provisioning of Data Center access ports
- Who: Network Implementation Team
- What: Provide deployment of ports for new server build-outs
- When: Servers to arrive October 1st
- Where: Brownfield DC
- Why: Implementation team is overwhelmed with requests
- How: Automation to deploy the access port configuration
- New or Existing: Existing
- Frequency: Weekly
- Steps: 4 to 10
- People: 1 to 3 People
- Approvals: Yes, 1 to 2
- Dependencies: Yes, 1 to 2 Dependencies on the required server-side information prior to starting
- Locations & Environments: Internal production
- Methods & Access: SSH-CLI with a User account
- Change Management: Standard change as it is repeatable work effort
- Business Value: Cost save associated with reduction of person hours & reduced manual error
- Acceptance Criteria: When the engineer can feed a list of Brownfield ports to the automation
We will begin our discussion on the topic of assumptions related to complexity and effort (aka duration). For assumption values we’ll use estimations as opposed to more concrete answers that were used earlier in the series. As with estimations, we need to remember that these are projections which can skew too low or even go too high. Even if these values don’t hit the mark, they are still useful and a valuable part of the process. It’s also important to note that over time these estimations will steadily improve, thereby making future estimations more realistic, meaningful, and most of all, impactful to your team.
Complexity
Complexity can been represented from multiple angles ranging from the number of systems or integrations, upstream or downstream dependencies, to engaging multiple teams or even environments (dev versus prod). Here is where we will start to analyze and interpret the data we’ve worked hard to obtain via the last two blogs. Items for consideration from said data gathering could include Steps, People, Approvals, Dependencies, and Locations & Environments, though Methods & Access as well as Change Management could potentially play a role as well.
There are a few different options at our disposal for the complexity scoring. One example is using a range of “Low-Medium-High” with Low rating involving only a single system or integration as well as limited amounts of other criteria. A Medium rating could contain mixed amounts of middle-of-the-road values, while reserving High for when workflow involves multiple systems, lots of moving pieces (integrations or services), people, dependencies, etc.
Another rating option is the Fibonacci scale commonly used with Agile Story Points. The Fibonacci scale is a sequence consisting of adding the two preceding numbers together starting with 0 and 1. An example of the sequence would be 0, 1, 2, 3, 5, 8, 13, 21, with lower numerical values associated with less complexity and higher values with larger, more complex items.
Choose an option that works best for you and your environment. However, we do want to be consistent in the type of scoring, so down the road we can refer back to previous examples.
New infrastructure at a remote branch location
- Complexity: High
- Within this deployment, there will be a significant number of steps to be performed along with multiple people and processes, as well as dependencies. There is also a greater potential for risk as the production environment would be affected with the introduction of new routing changes taking place.
Migrating from SNMPv2 to v3
- Complexity: Medium
- The previous request for new infrastructure as well as this request for SNMP migration have a single deployment frequency, however, the SNMP migration has noticeable reductions in other areas. Interpreting the data we gathered, there is a significant reduction in the overall number of steps to be performed and small reductions in the number of dependencies and type of work being performed on the change request (meaning it’s less risky). Taking these requirements into consideration, this request would be marked as “Medium”.
Create automation for the provisioning of Data Center access ports
- Complexity: Low
- As we start to review the last use case, we see the case as a smaller number of steps, people, approvals, and dependencies. It’s also worth noting that change management allows for a standard approval window for implementing the changes.
Work Effort/Duration
In terms of work effort or duration, we will focus the estimation around the amount of work our team will be on point to represent or work. Sometimes large-scale projects can include multiple teams and timelines that could have longer overall project timelines. However, we want to focus solely on the delivery from our team.
For the work effort, we’ll use a different type of estimation from complexity to offer a more unique value. We’ll categorize this work effort using a common yet familiar methodology by using a T-shirt size.
Extra Small (XS) | <3 months |
Small (S) | 3 to 6 months |
Medium (M) | 6 to 12 months |
Large (L) | 12 to 18 months |
Extra Large (XL) | 18 to 24 months |
New infrastructure at a remote branch location
- Work Effort: Large
- A new build-out may have a series of planning and estimation prior to approvals as part of a procurement process. Along with lead times for receiving new equipment there is a potential for timeline dependencies outside of our teams’ control, such as a new construction project. For these reasons, as well as the large number of staging and preparation steps, we will estimate this as a Large effort.
Migrating from SNMPv2 to v3
- Work Effort: Medium
- The SNMP migration would require a couple teams working together as part of the overall effort. Our team would support creating and testing the new network configurations in lab. When ready for the migration, our team would deploy the new configuration, engage the monitoring team for their updates, and work with the security team for their validation sign-off.
Create automation for the provisioning of Data Center access ports
- Work Effort: Small
- As we saw in the previous example, the automation for provisioning ports has a lower level of complexity. With narrower scope, the development and testing work for this new automated workflow could be performed in a smaller window of time as our team has created similar workflows in the past. Therefore, this work could performed in 3 to 6 months.
Putting It All Together
We’ve now completed the gathering of requirements as well as estimations, so we can establish where our next commitments or sprints will be directed. We did not include escalations as part of these efforts, as we wanted to maintain a steady state in the evaluations.
From the analysis of the three examples above for potential placement within our backlog of work, we would be working towards offerings with a higher return in value while spending a lower amount of effort.
As we look for potential placement within our backlog of work, we want to lean towards offerings with a higher return in value while having to spend a lower amount of effort. From the analysis of the three examples above, our backlog would be the following:
- Create automation for the provisioning of Data Center access ports
- Migrating from SNMPv2 to v3
- New infrastructure at a remote branch location
The creation of automation for provisioning is a request that is smaller in nature yet having a fixed parameter, allowing for a quicker delivery (lower effort) as well as reducing repeatable recurring manual workload and future use cases (high rate of return).
The SNMP migration would be second, as there is a defined amount of volume in the number of devices impacted. As this is a one-time remediation, there is a lower rate of return associated with the request; however, value of the new SNMPv3 would be applied to future devices via golden configuration updates.
The new infrastructure at a remote branch provides our business staff a higher value, though the longer lead times and procurement timelines lead to a much larger amount of effort. This last use case presents a future opportunity whereby the larger project could be broken down into smaller standardized sub-components. These smaller components could potentially lead to smaller efforts with larger rates of return.
Conclusion
In this blog post, we analyzed the data gathered from the previous blogs to establish our assumptions for complexity and work effort. With the completion of our work intake process, we reviewed our 3 use cases for order placement into our backlog for future work. With the work intake process, we are helping convey the true “ask” from the requestor while developing tangible outputs of requirements and assumptions for your engineering team.
From the gathered requirements, we began to extrapolate useable assumptions from our use cases for complexity and work duration. The introduction of these values will provide insight to the engineering team with their planning for team resources and helping establish higher value work efforts. However, these can also provide external feedback for the requestors in the form of more accurate delivery timelines along with a greater overall visibility and transparency of the process.
Work intake is helping create a “win-win” value in the request process for both the requestor and your team. We hope that you’ve found this introduction to work intake fun, different and useful. If you have any questions, feel free to join our Network to Code Slack community and ask questions!
-Kyle
Tags :
Contact Us to Learn More
Share details about yourself & someone from our team will reach out to you ASAP!