As a product manager, you have taken time to define a product solution for the problem, that you believe is so important and needs to be solved now. You would want to have that solution right away. But in reality, you would have to wait and without overspending on resources, including time, effort, money, code complexity, etc. This is where development methodologies, processes and tools come in and help you and the team manage these projects better.
Knowing how work is structured and managed using work management tools and how development teams develop new features while maintaining the existing product’s stability, is critical. The concepts and methodologies remain largely unchanged even if the problem being solved and project tracking software tools vary by company.
The seven methodologies of software development
Waterfall
Agile
Kanban – popular framework that adheres to the philosophy of Agile
Scrum – another popular framework that adheres to the philosophy of Agile
Lean
Rapid
Feature Driven
Waterfall methodology
The most traditional software development methodology, is the waterfall methodology, which follows a rigorous linear process. But given the rapid pace of the mobile, social, digital, prioritising speed and adapting quickly in everything you do is essential for the survival and success of your product and company. Not only does your application itself need to perform quickly, but you need speed in your decision-making and your ability to change course when necessary.
Waterfall prioritises a slow, careful, meticulously planned approach — not aligned with solving user problems. Waterfall It doesn’t have much to do with actual users.
Agile methodology
Agile helps teams write software more efficiently but that’s only if you truly understand what it means to develop in an Agile way. But “What is Agile?” it’s the million dollar question, and just as important what isn’t Agile. Beware there are lots of things called Agile— even when they are not, comfy shoes for stand-ups, post-it notes and whiteboard marker pens for flows and even software consultants.
The actual definition of Agile is found in the Agile Manifesto. The Manifesto makes it clear that Agile isn’t a methodology. It isn’t a specific way of doing software development. It isn’t a framework or a process. In fact, most of the things that are marketed as Agile tend to miss the point of what Agile actually is. What is Agile?
Agile is a set of values and principles.
How does a team become Agile?
Your team needs to make their decisions based on Agile values and principles. The decision making process is how a team becomes Agile. The values and principles have enough flexibility to allow teams to develop software in the ways that work best for their particular situation while providing direction to help a team continually move toward their full potential.
Much of the discussion around Agile has to do with following different practices, using various methodologies, and even developing with specific tools. While these things might help a team that is trying to follow Agile, they aren’t Agile in and of themselves. For example, while a team may find that having a daily standup is helpful, the standup is only “Agile” if the team is following the Agile principles and values, in that the standup helps this particular team to reach their full potential and deliver value to the customer.
When you understand this, it is easy to see that Agile is really a collection of beliefs that teams can use for making decisions about how to do the work of developing software. While this means the term Agile gets subjected to a great deal of abuse when people claim that this or that is the way to be Agile, it also means that if you truly understand what Agile is, it is surprisingly flexible.
Agile doesn’t make decisions for you. Instead it gives a foundation for teams to make decisions that result in better software development.
The Agile Manifesto, Values and Principles
The Agile Manifesto is only 68 words and very simply says that we can develop software better by valuing the items in bold of the list more than the items in italics.
We are uncovering better ways of developing software by doing it and helping others do it. (the best way for the team ‘we’ to develop software, continuously improving, and helping others in the team.)
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The 12 Principles of Agile
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliverworking software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity – identify things that do not add value and things that do (is an art) – is essential.
The best architectures, requirements, and designs emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
When you have a team that is following Agile they will be making hundreds of decisions each week in the way described above. That is what it means to be Agile. Making each decision based on the principles and values that the team has decided to follow so as to be high-performing, continually improving, inclusive team, that’s laser focused on adding value to the customer.
In fact, as time goes by, a good Agile team is probably going to change and refine the practices they use. A team might start with SCRUM and later find that Kanban is a better fit for delivering value to their customers.
The decision making process matters. If a practice is being selected because it looks like a good way to follow Agile principles, it is probably a good place to start.
Kanban Methodology
With the increasing complexity of the products teams need to develop and teams sometimes being globally distributed it is become increasingly difficult to avoid bottlenecks. Bottlenecks slow down a teams speed and create delays in delivering value to the customer. Kanban utilises a power of visualisation to increase team efficiency and deliver customer value faster. Kanban follows a very simple philosophy. It allows a highly motivated team to be able to visualise the progress of their work and the process through which the project will flow.
Kanban boards help visualise work, limit work in progress, and maximise efficiency, or flow.
Kanban boards can be built on walls, windows, whiteboards, or with the suite of digital tools like Trello and Jira. But bear in mind Kanban systems are highly unique to each team, and organisation. Through the STATIK method, each team can develop a distinctive system that will be the best fit. Teams will hopefully realise the benefits of building a Kanban board, and fill it with Kanban cards, and set up a work in progress limit.
How does Kanban visualisation avoid or eliminate the issue of bottlenecks?
Firstly what is a bottleneck?
When a developer finishes their work it needs to be reviewed by their peers and peers means other engineering team members, to ensure it meets the development teams coding best practices and guidelines and it doesn’t conflict with existing features that have been built already. This process is called a code review. It is common for work that has been completed by engineers to be stuck in this phase because an engineer provided feedback which required a the developer to go and make changes to their feature or improvement and push that work out again for code review.
Imagine this happening multiple times within a team, the team will hit a bottleneck. Typically development teams do not allow developers to pick another piece of work, unless their current work has passed the code review, and moved to the next step which is testing. Kanban also enforces a maximum limit on the number of items that can be in a particular stage of the process. Helping the team visualise the bottleneck, enables them to swarm, to figure out how to unblock themselves and make progress. Clear visualisation of the process flow of work and a work in progress limit helps to prioritise bottlenecks and focuses the team on resolving them as quickly as possible.
The Backlog
The first step in this process is a backlog, where the work that needs to be completed by the development team is listed. The backlog is managed by the product manager, in a prioritised order where the work which is required to be done immediately has the most details and is at the top.
As you go down further in the backlog, the amount of details available in each of these ticket reduces, and so is the priority of that ticket. Tickets with least details tend to capture the context or scope of the ticket at a very high level and you just list down the other details that will be captured later.
What you say from the inception of the study to its conclusion — how you recruit, write tasks, ask questions during a test, and lead posttest interviews — can all subtly (or not so subtly) affect how the test participant reacts.
As a user, I want to be able to login, in oder to buy things from the business.
Each ticket should cover a feature requirement called story. The Kanban board should show all tasks that the development team has identified for themselves to complete.
Ready-to-Develop
The next state or column is called ready-to-develop. Even though a ticket (scope of work) at the top of the backlog may have the most details, as a product manager you do run into situations where you have to modify some details or have it updated after clarifying with your designer or other stakeholders.
It is the responsibility of a product manager to take the next most important item from your backlog and have it updated. Once it is updated with the necessary information, you move it to the ready-to-develop column. When a developer is ready to pick up the next piece of work, they pick the first item in this column.
It is the responsibility of a product manager to take the next most important item from your backlog and have it updated. Once it is updated with the necessary information, you move it to the ready-to-develop column. When a developer is ready to pick up the next piece of work, they pick the first item in this column.
In order to eliminate the bottleneck, engineering team decides on the maximum limit on the number of items that can be in this column at any point in time, this is called the work-in-progress limit. Depending upon the size of the team and the lead time, for example a team of five engineers may limit the work in progress to five.
Once the developer has completed their work, it is now ready for code review, and to avoid a bottleneck in this critical phase as well, a work-in-progress limit is specified, again this might be 5, for a team of 5 engineers.
Say there are five tickets in code review, the team will swarm to reduce the number of tickets in code review before moving to their next ticket. Ideally, both another engineer and the software architect, should perform code reviews. A code review performed by a peer engineer has a different purpose than one performed by the architect.
Tickets in testing are moved on buy the Quality Assurance (QA) team. Depending on the size of the team, will depend on the work-in-progress limit.
Once the ticket enters verified the product manager steps in to verify the completed work as well. This process where product manager verifies is called user acceptance testing or a feature sign-off from product manager, where you verify that the work has been completed and it meets the product requirements. In order to avoid bottleneck in this phase as well, there is a work-in-progress limit.
Utilising this board will enable you to calculate the lead time based on the time taken for an item to actually move from the ready-to-develop state to the done.
When adding a new item to the Backlog, it needs to be reviewed and discussed before it’s Ready to Develop. Cycle time refers to the time a ticket takes to go from the Ready-to-Develop to Done. Lead time, is the time taken to take the ticket from Backlog to Done.
Scrum Methodology
While Kanban is great at enabling teams to visualise the process and the flow of work, it’s not that effective at enabling teams to manage complex products where the requirements are changing, and the complexity of the product also requires comprehensive testing to be conducted, on every release, to ensure that the deployed product is stable.
Scrum enables teams to self-organise and work together. A self-organising team is one where once they have a clear idea of what needs to be done and the expected timeline, the team decides on how to get that work done. Scrum has a clearly defined set of guidelines which includes the roles that need to be played by each team members, the different types of meetings that need to be run, what needs to be covered in the meetings, who needs to attend each meeting, the meeting frequency, etc. Scrum also provides information about the tools that team can use during these meetings. Scrum enables teams to manage work more efficiently than other development methodologies.
Team dynamics is at the core of the scrum. The purpose of the guidelines is to open communication channels between the development team members and the product manager, so there’s clarity around what is expected of each other to share project progress, etc. Scrum motivates a team to be transparent and focus on learning and improving.
Product requirements are not set in stone. In many instances when you’re managing a medium to large size initiative as a product manager, while some requirements are clear, some requirements require more collaboration between the designers and the development team to refine the solution, and to complete the cycle of user validation and stakeholder feedback.
The project often needs to progress while some elements are still being defined. On more complex projects, the scope is often broken down into manageable chunks, and executed in a specific order to ensure that as you develop features, with small release cycles, they fit together to continuously deliver a stable product in an iterative manner. The outcome of a well managed Scrum are teams that are able to develop and maintain complex products despite requirements not being fully flushed out from the very beginning.
Scrum is an elaborate process, that covers the end-to-end product development cycle. Starting from the product manager to have a fully functional deliverable at the end of this short release cycle.
Scrum Product Backlog
Similar to the backlog for Kanban, the product backlog refers to the prioritised list that contains various items ranging from feature requests from the sales team, to bugs reported by users, to a roadmap feature.
The highest set of items have more detail (to provide clarity) and focuses on the work that the development team will do next. The backlog is a dynamic list, and needs to be updated and maintained by the product manager based on any new information or feedback that they receive from internal stakeholders or customers or market changes.
The Scrum Team
The Scrum Team includes development team members, iOS developer, Android developer, back-end developer, front-end engineer or full stack developer. It also includes QA team members, product owners and product managers.
The product designer and data analysts might join the Scrum meetings when requires, and in some organisations aren’t considered as part of the Scrum team.
Product Manager Vs Product Owner
In Agile teams, the Product Owner has the responsibility of maximising the value of the product, and represents all stakeholders, including customers and users.
The product manager studies the customer’s wants and needs, whereas the product owner makes sure that product development is following the product roadmap. The product manager decides what is going to be built or adapted and the product owner makes sure the development team does just that.
co located
Story Owner
The role of a story owner is to design and deliver great features in a continuous delivery process. This can be done by a product owner or product manager. A story owner is responsible for delivering one great feature at a time. The story owner takes a story (a feature for a user), through build, test, release, announcement and measurement.
In most cases, the product initiative, epic and stories are assigned to the product manager. During the sprint, a ticket capturing a user story is assigned to a development team member.
Writing Rockstar Agile Tickets
Managing dozens of products and hundreds of releases, creating value for users, is not easy to coordinate. Diligence and clear communication allow for the delivery of timely and valuable software consistently. One of the key tactics is writing robust tickets. There’s a big difference between a mediocre ticket and a rockstar ticket.
The first step is understanding what makes an effective ticket or user story. For this use the agile INVEST principles:
Independent — of other tickets
Negotiable — not a specific contract for features. Engineers should provide input.
Valuable — provide user and business value
Estimable — include enough information to estimate
Small — manageable enough unit of work
Testable — a QA or PM can test the end result
VALUE
The best way to approach the INVEST principles, is to start with the VALUE:
As a <user>I want to <function/unit of work>So that <value>
This simple outline states the user value (V from our INVEST principles). It is important to distinguish between what we expect the user to do and what the user actually wants to do. It sounds simple but this is where Product Managers oftentimes miss the mark.
An example:
As auser,I want tosign upso thatI can log in.
Does the user really want to log in? Does the user see value in logging in? Is the benefit really logging in or something else?
A better example:
As auser,I want tosign up so thatI can make purchases faster.
It is easy to default to the generic “user,” however, most products do have different target audiences and personas. And our user story will be stronger if it focuses on a specific type of user, rather than a generic one. Again, this may not seem like much, but these tweaks can help save time and hone in on the most valuable stories and features.
So let’s drill down a little further and see if we can be more specific.
As arepeatshopper,I want tosign upso thatI can make purchases faster.
We have now clarified that we are creating value for a repeat shopper, the kind of user for whom a business definitely wants to provide a great experience.
Product managers need to add business value by adding product value. If value is added with each user story, then product value becomes inherent in the process—and the business ROI will always be positive. Our team will be happy, our users will be happy, and our product will grow.
SMALL
Small Is something that can be completed within a two-week sprint. Anything that will take longer than two weeks will most likely have unknowns and be broken into additional steps.
Small can also tested with the Acceptance Criteria, ideally a ticket’s Acceptance Criteria should be below 8 (+/-).
As arepeat shopper,I want tosign upso thatI can make my purchase more quickly.
There are many different signup flows, signup flows vary. Therefore, it is hard to say definitively whether this user story is small, it depends… Some sign up user stories could include:
As a shopper, I want to add my address so that check out faster. As a shopper, I want to add my credit card information so that I can check out faster. As a shopper, I want to include preferences so that I can get product recommendations.
What is a Sprint?
A sprint is a short period of time during which the Scrum team will focus on completing a defined scope of work.
What is a Scrum Master?
Is the team coach within each Scrum team. They help the team refine their adoption and practice of Scrum, over time. They understand the work being done by the Scrum team and they help in organising and structuring that work. They promote transparency within the Scrum team by raising issues or requesting team members help other team members when required.
Most of the meetings in the Scrum methodology, will be run by the Scrum Master, they run the meetings, starting from sprint planning, daily stand-ups, to sprint demos and retrospectives.
The Scrum Master as the driver of the meetings, is responsible for scheduling, writing agenda, running the meetings, capturing the minutes and key takeaways, and most importantly, minimising any distractions in the meetings, by keeping the team focused on the agenda.
What is Sprint planning?
Sprint planning kicks off a Sprint. It is used by the Scrum team to determine what can be developed, tested, and delivered within a sprint.
Remember, sprint is a preset short period of time which usually ranges from one to four weeks. Sprint planning is typically limited to two hours.
A Sprint planning meeting needs a prioritised list of items from the product backlog, usually the top of the product backlog, and each ticket has details from the engineering team to clarify; what is expected, and what needs to be developed. The product backlog could contain hundreds of tickets, and it’s important to focus the teams attention on the top, say, 15 tickets for the upcoming sprint.
The list of top prioritised items is created by the product manager for the sprint planning meeting. The list of items inputed into the sprint planning meeting is prioritised by the Sprint goal. Often the sprint goal gets overlooked in favour of defining and organizing the sprint backlog. But sprint goals are a crucial component of sprint plans and can help teams and stakeholders more effectively focus, prioritise, and align work.
What is a Sprint Goal?
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. Sprint goals are the result of a negotiation between the Product Owner and the Development Team. Sprint Goals should be specific and measurable. While the selected work for the Sprint Backlog represents a forecast, the Development Team gives their commitment to achieving the Sprint Goal.
Sprint Goals should be specific and measurable but they doesn’t mean they need to be SMART. Goals shouldn’t be too vague. Examples might be:
Get feature X ready for release (Sprint Goal is delivering a feature)
Check if the architecture enables the desired performance (Sprint Goal is addressing a risk)
Test if users are willing to register before using the product features (Sprint Goal is testing an assumption)
Sprint Planning Meeting
During the sprint planning meeting, the team has the list of product backlogs based on determining the work involved to deliver the sprint goal by picking one ticket at the time. Starting from the top of the list and discussing how to build that particular scope of work. They proceed to estimate the work involved in it, that is the cost of the ticket. This cost is an estimate and is not expected to be accurate at all. The tickets cost is based on how the team plans to deliver a ticket.
Once the team has discussed how to deliver a solution, they will actually utilise the costing technique, to cost the ticket. The cost is not based on the number of hours or days or people required to deliver a ticket, it’s based on the difficulty of implementing a ticket. This ticket could be a user story, a task or a bug.
Companies tend to cost tickets by using story points which follow the Fibonacci series, 0,1,2,3,5,8,13,21. Tickets that are estimated to be larger in size, for example are 13 or 18 or 20 points tickets, are broken down by the development teams into smaller tickets to reduce the risk of not completing the ticket. Team members share the rational behind the cost. This information is then used to refine the details of how to deliver the ticket and finalise the cost, that is the story points for the ticket.
Planning poker cards, is a popular framework used for costing, where a card is used to show their estimate.
Then based on the number of story points that the team has completed historically, then the list of costed ticket is calculated and utilised to determine the updated sprint goal. For example 60 story points was completed by a team of 10 engineers in two weeks sprint cycle, sprint velocity is 60 points, the sprint goal is then adjusted by the product manager.
The goal of each sprint is to provide a completed functionality versus incomplete or partial functionality. The outcome of the sprint planning meeting is a list of tickets that have been costed and the team captures the details on how to build each item in the sprint.
Daily Standup
The daily stand is a 15 minute, highly focused meeting that happens at the same time and place every day, typically in the mornings before the team starts working. The purpose of the meeting is for everyone in the scrum team to be on the same page. Each Scrum team member shares their updates for the following;
What did they do yesterday? What do they plan to do today? Are there any blockers?
This way, a team member can voice their concerns or any blockers that is affecting them from achieving the sprint goal. The product manager or a scrum master may utilise this meeting also to share their concerns if the team is lagging behind the sprint goal or applaud the team if they’re ahead of the sprint goal. They may also use this to raise concern if they see someone being stuck on a ticket longer than required or estimated, but the team member did not raise it as a blocker.
Sprint Demo
At the end of the Sprint there is a Sprint Demo. This is where the team shines. The audience for the Sprint demo depends on the company culture. The scrum team, which includes the development team and QA, showcase the work that has been completed during the Sprint.
Once they have demoed the functionality, they focus on the sprint deliverables or goal, the completed work that the team achieved during the Sprint. Every ticket is marketed as completed and successfully tested. The work may or may not be deployed to production, depending on the roadmap. In Kanban each completed ticket is deployed to production immediately.
Sprint Retrospective
A retrospective is when the team comes together to discuss, in a constructive manner, focused on improving the team’s collaboration, what worked well during the sprint, for example, the design prototype from the product designer had all the details captured clearly, they didn’t require any other clarification from the designer, and allowed the engineers and the QA team members to develop and test it successfully. You can discuss what didn’t work well in a sprint, for example, the setup to test a new feature took a lot of steps, adding a delay to verify the ticket with the QA and product manager.
What can we improve for the next time? The team agrees on improvements for the next sprint. Normally it’s no more than three items:
Keeping the stand-up updates on what needs to be done or completed at a high level
Identify the action items that need to be discussed outside of the stand-up meeting since it’s taking up everyone’s time.
Arrive to the stand-up meeting on time.
This is a comprehensive process that focuses on getting things done by promoting clarity and transparency, creating open communication channels for teams to discuss any issues and challenges that arise, and to come together as a team to share what worked and not worked during the sprint so they can learn and grow from the process as well.
Sprint Velocity
The rate of progress, that is the amount of story points completed during the sprint is called velocity and is determined using the burn down chart. This burn down chart is plotted using the sprint days as the x-axis and the story points on the y-axis, for example, if a team’s velocity is 60 points on an average, then during sprint planning, the team uses this historical data to determine the work that can be completed.
Sprint Epic
An epic is a set of interrelated stories, user stories, that can stand alone as an independent body of work. Depending upon the scope of work and the complexity of the work involved, an epic can take a few sprints to complete because it has a lot of stories associated with it.
Remember stories, or user stories, are written from the perspective of an end-user with a clear set of detailed requirements that need to be developed and tested to mark the story as done. It is focused on narrating a single and simple job that the user desires to be done, or a need that the user wants to have satisfied.
