Agile Software Development: guide for stakeholders

Learn about what will happen during the agile software development process when delivering projects with Scrum as an Agile framework. You, as a part of the team, will be needed to make all of that happen. However, the required level of your contribution will vary.

This article will help you understand your role–when and why your input is indispensable for making the project successful.

Table of contents
1. Stakeholders as a part of the team
2. Agile for stakeholders, step by step
3. What is required of stakeholder and why?

Agile stakeholder engagement

Stakeholders, their roles and level of engagement can vary depending on the project, client, and individual character differences. The stakeholder owning a small startup could be much more interested in project management structure than a project owner working for a large company who additionally has many parallel projects running. What’s more, a stakeholder with a solid business perspective would know how important it is to keep up to date and give business insights to the Agile team so the project will always be focused on business value.

Unfortunately, not all stakeholders are aware of their engagement importance, and that is definitely a challenge. It’s a negative aspect the project team has to deal with but above all, it’s bad for the product and the client. The project’s success depends not only on the quality of technological solutions but on how well the delivered product is adapted to the real business and users’ needs, and this aspect can only be examined with a stakeholder’s active participation.

Agile Software Development for stakeholders step by step

Agile software development is made up of various elements and actions–a part of them happens once and some repeat until the finished product is produced. Below you will find what constitutes the process, what each phase is about and who is involved in it.

What happens before the iterative process begins?

Introductory workshops and brainstorming 

The essence of the workshops is about discovering. The product is the first to go–the main idea drafting the overall vision and goal, and smaller ones that pin up the essential additions. The next aspect is discovering and defining the audience with their overall needs. All of that must be based on a strong business perspective given by the stakeholder. The workshops deliverables are:

Scope–of the project with the product goal
Product requirements in a form of user stories Product Backlog–an action plan for delivering requirements

Participants: the team, Scrum Master, PO, stakeholder

---

When building a product with us, at the end of the workshops you will also get:

the more exact cost estimation
preliminary release estimation
project card

---

Product Backlog Prioritization

Setting priorities is an essential thing in software development. Requirements prioritization is needed to know where to start the work, and to be sure that the most important elements are delivered at first. Giving a logical structure to the work order is necessary but can also be demanding, that’s why we’ve covered the topic in a dedicated article on Backlog prioritization. Be sure to check it out.

Participants: the team, Scrum Master, PO, stakeholder

Iterative phases of development process

1. Sprint Planning

Sprint as you already know is the short period during which the development team works on specific increments. As with everything in Agile development, the sprint has to be planned too. The sprint planning deliverables are:

Sprint Goal – the main aim the team focuses on

Sprint estimating – how much work can be done 

Sprint Backlog – list with tasks a team will be working on 

Defining a DoD (definition of done – what must be delivered to consider a task as done)

Sprint Backlog Prioritization – what will be done at first

Participants: the team, scrum master, PO, stakeholder optionally

2. Sprint happening

Usually, the sprint is a period between 2 weeks to 1 month. Once established, the length of the sprint does not change throughout the process. During the sprint, the team members work on tasks from the Product Backlog. The sprint should end with producing a working increment or its part. While working, the team takes into account arrangements set during Sprint Planning. Each day the team has a meeting called daily standup or a status meeting that is the occasion to share what the team member will be working on and, if necessary, what are the challenges to overcome.

Participants: the team, PO, Scrum Master, and stakeholder optionally 

3. Sprint Review

The meeting during which the team presents the working increment to the stakeholders and other participants. (Sprint Review can be an open meeting) As the stakeholder, you should use Sprint Review to inspect the work results and to give feedback. It is also a good moment to pass on new-born ideas based on presentation of the built increment and discuss future changes if the need arises. Generally, Sprint Review helps to check the progress toward the project or product goal, so you can be sure the project moves in the right direction.

Participants: the team, Scrum Master, PO, stakeholder  

Important to notice
If you define new requirements during Sprint Review, then we will be talking them through and giving them priority during a joint session of Product Backlog Refinement.

4. Sprint Retro

An event aimed to combine inspection (how was it) with adaptation (how we can adapt the process to better results). The team evaluates the sprint—in terms of roles, interactions, tools, and processes—and indicates what went OK and what can be improved with the next iteration to provide better results.

Participants: the team, Scrum Master, PO, and stakeholder optionally 

5. Product Backlog Refinement

The goal is about going through the Product Backlog and checking if something has changed– priorities or maybe some requirements need to be added or omitted. This checkup is done by PO with your cooperation. The big importance of Backlog Refinement comes from, among others, the team and the project capacity. The backlog can not be extended without limits and delivered within the original time estimation. It is good to be aware that very often if one element is added and marked with a high priority, the other must be omitted, so it’s all about prioritization based on business value.

Participants: PO, stakeholder, Scrum Master, team optionally
Important to notice
Backlog Refinement can happen anytime when it is needed. Not necessarily must it be at the end of Sprint – after Sprint Retrospective. However, if there is a need to choose an appropriate time, then the end of the Sprint, and before planning a new one, is a good time to carry it out.

and the cycle repeats as the new Sprint Planning is started…

Agile is everywhere

The Agile process–its elements and their sequence– has a very logical structure. It can be compared to, for example, loading a truck (Sprint Goal). First, we plan and analyze how many packages will fit in the truck (planning, refinement), and then decide which are the most important and must be arranged so they can be taken out as quickly as possible (prioritization). Afterward, the parcel preparation process begins: we fill the package with content, close it carefully, and then complete the next one (Sprint happening). Finally, we put them in the truck (Sprint Goal achieved).

As you can notice, to make all that happen effectively we can not omit any of the steps. Without good planning, we can produce too many packages that won’t fit in a trunk, and as a result the resources –money and time will be wasted. Not closing the packages carefully, can cause the content damage and so on..

What do stakeholders do in software development project?

You, as a stakeholder and the representative of a business, are the source of knowledge an Agile development team really needs. And what exactly are you supposed to do and what to share?

Give business perspective

It means introducing the team to the business reality of your company, e.g.

determining the goals, values, or challenges of the company in the context of the product; sharing insights on competitive products or markets, etc.

When? Introductory workshops, Backlog Prioritization and Refinement, Sprint Review, and every time while giving feedback. 

Why? Because the team doesn’t know your company, as well as the industry you operate in, and you are the best source of knowledge. Remember that to build a successful product, except for the technological experts, business (company) knowledge is essential.

Give users’ perspective 

This is, in a way, an extension of providing knowledge about the company– who are the users of your product? What needs or problems do they have? The second option of gaining the users’ perspective is to help the software development company in reaching the audience to conduct user research on their needs and pain points.

When Introductory workshops, Backlog Prioritization and Refinement, Sprint Review and every time while giving feedback
Why? The users are the ‘final cell’– they buy and use the product, and their needs must be included and met by the product.

Create valuable qualities with a team

The common goal of parties involved in the project is to work out needed deliverables. And it must be admitted that there are quite a few of them. Nonetheless, they are crucial to building a valuable product. What qualities will you be working on? Project scope, product goal, list of requirements in form of user stories, etc.

When? Introductory workshops, Backlog Prioritization, and Refinement, 

Why? To create a base for successfully running the project and building a product with value for the users and business. It is the most needed groundwork that has to be done for the project to be successful.

Prioritize qualities with the team (requirements prioritization)

What the Agile team can see as important and first to build may not necessarily be the most significant from a business perspective. There are no people who know it all, so exchanging perspectives on priorities and deciding what will be produced first is the bottom line to delivering a good product.

When? Backlog Prioritization, Backlog Refinement

Why? To produce the base first – it’s the best-proven method of project risk management 

Providing feedback

The Agile team requires thoughtful and argument-based feedback to continue with work and introduce adjustments to make the product better adapted to the business needs. Remember to give feedback that provides value.

DON’T: my assistant/boss doesn’t like the design 
DO: it won’t work because users care about….

When? Sprint Review, or during sprint if decided

Why? No feedback means no knowledge if anything must be changed.

Important to notice

Delayed feedback is also wrong. Agile software development is like a set of communicating vessels. The team having no feedback will continue with the achieved effects to produce another element, so late feedback regarding the necessity of changes means that already built increments, as well as those being delivered at the moment, must be changed. This means wasted time and money. On-time feedback is a crucial part of: managing the risk, keeping the cost and releasing estimations valid.

Participate in meetings

Meetings are your knowledge source of the work’s results. For instance, if you would like to see the produced increment (the product’s feature or its element) you need to participate in a Sprint Review. What’s more, from our experience we know that you will have new ideas and fresh requirements when you see the ready increment. Software projects are pretty abstract when theorizing, they become real when something is produced. 

When? Introductory workshops, Backlog Prioritization, Backlog Refinement, Sprint Planning (optionally), Sprint Review

Why? To be aware if a team is on the right track, to provide feedback, to know and manage the risks and problems, and to change something when needed.

Participate in the risk management

This is the shared task with a PO. Together you can talk the risk through and when you have an understanding of what is going on, what are the risks, and options to manage it, you can make decisions.

When? Every time when needed

Why? Software development is a complex process and no one can control all of its aspects. Impediments like: all that you don’t know and can happen and shortcomings: bad competition analysis, wrong value prioritization, little knowledge about the user or undefined important business value. All of that can contribute to the emergence of risks that need to be managed. The more you know about the project, the easier it will be to handle it.

Cooperate with PO to understand the project

When running a software project, there is a need for trust in competency. The PO is the expert who has the best situational overview. Let’s imagine a situation when you want to significantly extend the project’s scope, as in the process you have gained knowledge about very important functions the product has to provide. The Product Owner has knowledge of the team’s maximum capacity which indicates if the project’s scope can be extended with keeping the current budget. If PO says that it is not possible, it should be based on parameters and facts. You can always ask about the reasons but please trust PO’s expertise.

When? Always
Why? Because PO is the main communication medium between all parties involved with the project and has the biggest project knowledge.

Hopefully, the above tips and knowledge will help you take an active part in Agile project management. Although software development is a complex technological process, its rules, in terms of project management, are openly communicated and that helps to be involved. Believe us, it’s only for the benefit of your business to have stakeholders actively engaged in the product building.

Let’s do this together. 

Interested in running an agile project to build a great product? Contact us