JIT, Iron Triangle of Planning, Non-Functional Requirements
JIT, Iron Triangle of Planning, Non-Functional Requirements
Edition #17- Monday 3-2-1
Hello 👋,
Welcome to the Monday morning newsletter ☕️.
Every Monday morning, receive 3 ideas on how to work more effectively in product and dev teams.
To receive articles like this, please subscribe to The SEO Sprint 👇.
🎓 Think Like an SEO Product Manager
Do you have trouble getting SEO projects executed?
Then check out my course designed for SEO professionals to think like product managers and use tried-and-tested techniques to get projects executed 👇.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
1) Just in Time (JIT)
Do you ever wonder why your tech teamwork is in weekly or fortnightly sprints?
The theory behind it is called Just in Time (JIT).
JIT is all about producing high-quality work efficiently by eliminating waste, inconsistencies and unnecessary requirements in the workflow.
This means that when working with tech teams, they focus on discovering, planning and shipping small frequent releases that help drive business results.
This reduces the time it takes to get changes in front of customers.
Why it matters
When building a complex project the key problems are uncertainty and complexity.
When a team makes small and frequent releases (JIT approach) it can help avoid unnecessary complexity if properly used.
The JIT approach is just like mathematical theory in dealing with non-linear problems: feedback-based approaches which in maths is called control theory.
If the JIT approaches are not followed, then what can happen is the same issue as mathematical control theory: a huge deviation in the intended outcome.
This deviation from the solution can mean that in both software development and website development, a huge waste of time and energy in teamwork.
How to Action
Every single project can easily become complex and full of uncertainty.
So, as the SEO or product lead, it is important to work with your team to reduce complexity and uncertainty by:
📈 Clear outcomes - Identify the changes in use behaviour you want to see.
🥅 Set goals - Setting clear benchmarks, metrics and goals to measure success.
📝 PRDs - Write requirement documents to get everyone on the same page.
🧠 Team Wall - Use team walls to build shared understanding.
🎟️ Tickets - Break down projects into tickets 2-5 weeks before needed.
The outcome of discovery, planning and breaking down ideas into realistic tickets just in time is that you’ll start to see realistic dev tickets that fit into the dev backlog and can be ruthlessly prioritised.
2) The Iron Triangle of Planning
How can you make a project get implemented faster?
All projects are constrained by three key factors:
📏 Scope - The features or work of a project that needs to be completed.
⌚ Time - How long it takes to complete a project.
💰 Resources - The budget, team and tools needed to do the work.
These three constraints are commonly referred to as the Iron Triangle of Project Management created by Martin Barnes in 1969.
Why it matters
The Iron Triangle of Project Management is based on the following assumptions:
The quality of work is constrained by a project's budget, deadline and scope.
The business can trade between the three constraints.
The quality of work suffers if one constraint is changed, but others don’t.
However, in product and engineering teams, trading between constraints is not always possible.
Specifically, doubling resources does not have an immediate impact on scope or time. In my experience, doubling the development team to build a website doesn’t result in half the time to build the website.
In fact quite the opposite. Any system or process is constrained by Conway’s Law.
When increasing the number of people on a project increases the amount of communication needed to align the different team members (e.g. planning, onboarding, coordination, etc.).
So, when trying to get a project executed faster and you double the dev team it can actually:
⏳ Increase the amount of time it takes to build a website.
🔽 Lower the level of quality of the work
How to Action
If you want to get tech teams to deliver a project faster, and maintain quality, I’ve found that your best bet is to:
🗣️ Improve Comms - Speak to your developers on a regular basis.
🔭 Reduce Scope - Prioritise the brief and requirements, to keep focused.
⏳ Increase Time - Extend the time to give devs room to find a solution.
3) Non-Functional Requirements
Do you notice why certain businesses can release code without impacting site speed or accessibility?
The answer is they might be using non-functional requirements.
What are non-functional requirements?
Well, to answer this we need to understand functional vs non-functional requirements:
Functional requirements - These are requirements that must be implemented for a user to complete a task. For example, “A user can view multiple images of a product from a product page”.
Non-functional requirements - These are requirements which specify the quality attributes and how the system should perform. For example, “A product page should load in 3 seconds”.
A few examples of non-functional requirements include:
Web Performance
Accessibility
Security
A good example of technical quality attributes can be found in any Lighthouse report you run on a website.
Why it matters
Great, technical jargon from engineers. Why does this matter to SEOs?
Well, just like everything, it is how you use non-functional requirements vs functional requirements.
As a PM, and now as a consultant, I notice a lot of teams focus on success criteria from sprint release to sprint release, so tickets can be marked as complete.
The success criteria are usually based on the contents of the SEO tickets agreed upon by the team.
However, what a lot of teams miss is thinking about the system-wide success criteria that each release needs to meet.
For example, any release to website production needs to meet an agreed set of Core Web Vital criteria before it can be released. If it doesn’t meet the criteria, then developers need to refactor the code so it can be marked as “complete”.
This happens in every release.
How to Action
Testing for non-functional requirements is actually something SEOs do all the time.
For example, did you run a weekly or monthly web crawl on a website? Ever pick up technical SEO issues (noindex, canonicals, etc.) when the development team made a release?
Yeah, you’ve been checking for non-functional requirements.
The problem isn’t picking them up but getting teams to action issues found from the tests.
I follow a simple process to get non-functional requirements actioned:
🤑 Get buy-in - Work with developers to build a business case to build a QA process.
📊 Metrics - Agree with the dev team on what quality attributes need to be measured.
🚦 Priority - Agree with developers on the priority of issues detected (P1, P2, P3, P4).
🧪 QA Testing - Agree with the developers on the QA process and who is responsible.
🔨 Tooling - Invest in tools that can automate a lot of the QA testing to pick up issues.
Remember not all things detected should stop a release and they should be BIG issues.
💽 The SEO Case Study Database
I just released the SEO Case Study database. A curated and growing database of 350+ publicly available SEO case studies, experiments and studies.
Check it out 👇👇👇
How did I do this week?
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.