Tag Archive

Tag Archives for " Agile Scrum "

Who is the scrum master in agile?

Agile without the Scrum master is like an orchestra without a conductor. In my years of Agile, this person is always the central person in the team.

Who is the scrum master in agile? The scrum master is the organisor of an Agile development. Think of this person as the process manager of Agile or if you like, the linchpin that brings all the related project team together to follow the Agile process.

Now that you understand from a high level what a scrum master does, you need to understand exactly what they do and how they fit into the process. If this interests you, please read on for more information.

What does a Scrum Master do in an Agile Scrum?

During an Agile scrum all project team members huddle together for a quick “stand-up” meeting. The reason it’s a stand-up meeting is so it physiologically reduces the expected duration.

Meaning it is likely to be shorter and concise if you do not sit down, well that is the idea.

The Scrum Master is effectively the organiser of the scrum and really wants to establish three key peieces of information from each scrum meeting attendee:

  • What did you actually do the day before?
  • What is your plan for today?
  • Are there any blockers in your way?

Even though this may sound like the scrum Master is similar level to a project or programme manager, in reality this is not the case. The scrum master is just responsible for facilitating the scrum, not the outcome of the project or programme o work.

What is the Scrum Masters Objective During a Scrum?

During the scrum, we just established what the scrum masters role is. But what is their objective you may be thinking? Well they have a challenging task of keeping the team focused and most importantly avoiding blockers that could prevent progress within the current, or future sprints.

As well as this, they have to make sure the team is in agreement with the direction of the day. For example, if you are asked “what is your plan today?”. Your response may be: “Work on the second drop down list data feed”.

There is a chance that your response my cause an objection or suggestion to this a bit different. This is where scrum master is valuable to keep everyone on track and reach an agreement.

What Authority Does a Scrum Master Have Within an Agile Project Team?

As discussed earlier, the scrum master is not a project or programme manager. And in fact they may not have any real project level authority at all. However they do own the “process”.

What does this mean? Basically they can decide how the scrum is organised, who speaks next. Or even if they want to make alterations to the sprint duration.

Bare in mind, all of this is in theory. However, in my experience of testing throughout the years, the real authority to make these decisions stick depends on the politics of the company you work for and how respected that individual really is. But on paper, they should have the ability to do this.

What Value Does the Scrum Master Add to the Product Owner?

Apart from the actual scrum itself, the Scrum Master also ads value to the Product owner. In particular making sure that the team fully understand the product backlog and importance of having very clear and understandable backlog items designated to each sprint.

What Value Does the Scrum Master Add to the Dev Team?

The value add here is helping the development team come up with the highest quality products that they can. This is mainly by helping to remove any blockers that may be preventing their progress within the current sprint. Also making making sure they understand the sprint plan and how that related to the product backlog.

Overall what value does the scrum master add to the organisation?

In general the scrum master works to help the organisation understand and adopt the scrum process. Initially it can be hard to get a project team to conform because they are not used to the new process. This is where the scrum master really adds value.

What is a Typical Scrum Master salary?

According to glassdoor, a scrum master in the United states earns, at the time of writing, $115.992 and in the UK, approx £50,000. Obviously these are averages and depending on where you live, the company you work for, this can vary quite significantly.

Do you need a degree to be a Scrum Master?

You don’t need a degree to become one, but you do need to have a good understanding of Agile Scrum. In addition to this, it is advisable that you have a good idea of how your company works, the products they use and the culture of the organisation.

This is because the Scrum Master needs to work with a lot of people of varying levels of skills and hierarchy, and to gain their respect and do well, you will need these skills.

How long does it take to become a scrum master?

To become a qualified Scrum Master you will need a qualification. For example the Certified Scrum Master. However, this is a certificate, it will be the stepping stone in your carrer, much like an ISTQB foundation qualification is a stepping stone in testing.

My point is, you will still need some experience in the company to really be considered for the role. Also, bare in mind in reality there are people out there now fulfilling this role of Scrum Master without this qualification, much the same as there are testers without ISTQB qualifications.

Related Questions:

What is the Certified Scrum Master (CSM) Exam? CSM is a certification provided by the Scrum Alliance. Once you have complete the CSM training you can can take the exam and have the opportunity to be certified. The course training is typically done over two days with a qualified trainer.  These trainers are referred to as “Certified Scrum Trainers”.

How long is the CSM exam? The exam is about an hour and is done using an online system. It is possible to pause, resume during the exam, so the duration is the actual time. The elapsed time could be longer if you pause and take longer to complete it, if that makes sense.

To pass the exam you need to get at least 24 out of the total 35 questions that are asked. The great thing about this exam is that once you submit your answers you can get an instant score. This is because it is a multiple choice question exam, meaning you have fixed answers.

What happens if you fail the CSM Exam? If you fail the exam you get the chance to re-take it again. As long as you do this within 60 days you won’t be charged. However, if you fail it again there will be a fee tat you’ll need to pay to try again.

 

How Do You Split User Stories in Agile Scrum like a Ninja?

Intro - How to Split User Stories

In the last 16 years, the Agile Scrum methodology has established itself as the top gun in the software development industry. About 71% companies today rely on Agile instead of the older techniques to get things done.

With its streamlined & meticulous processes and emphasis on modularization (User Stories), it has made the software development a more organized task.

Each User Story consists of a feature or functionality that the development team works to implement, in order to address a need of the client.
Let’s look at a few questions that most people are curious about when it comes to splitting the user stories:

What is splitting User stories in Agile Scrum?

Splitting of stories is very much like breaking down a big task into several small tasks. One big story is broken down into several smaller child stories that each play a role in the overall development.

Splitting should be done with the intent of delivering value to the client & making the development process relatively easier.

This is best achieved by writing child stories which target a capability of a feature. A feature is in itself a working unit that can function on its own, and as part of the bigger product. This translates to real and tangible progress for the product and the team. It also means that the team can quickly develop and test, and get feedback on it from the client.

From the development team’s perspective, the thumb rule is to split stories in a way that every sprint has a piece of feature/functionality that can be developed and tested properly.

2. What is Horizontal Splitting?

This approach involves splitting the story in terms of architectural layers. This implies that the entire story would be split on basis of work belonging to different teams: D.B, Front-end/U.I, Back-end, Security, etc.

This kind of splitting results in a situation where the customer can’t have anything useful or worthwhile to go with until everyone working on the different layers finish their respective share of work.

Development involves coordination of different teams (and people) handling different architectural layers. This approach jeopardizes the value& the process, if one team delivers their share of work, but the other doesn’t.

A working feature or functionality requires all layers to be working in tandem. If development is done layer by layer, there is an increase in the overall complexity. Unless one layer is ready, integrated and working fine with the other layer, testers can’t really test anything, thereby creating latency.

What is Vertical Splitting?

This approach to splitting revolves around splitting the entire story into several doable features or functionalities.This results in child-stories which when implemented, work to deliver some tangible result that’s valuable to the client.

A sprint’s worth of work creates substantial value to the client and helps the team in form of feedback that they can use to improve the functionality.

This is argued to be the best way to move ahead, since it implies that with time, the development team is creating usable functionalities or features. These work independently to get something done, and eventually integrate into the system to work with other such functionalities.

This improves the cohesiveness between different members of the development team, because they are all working on things that together contribute to the output. Also, it’s easier for them to coordinate in terms of how their respective share of work integrate.

What is splitting by business rules?

This approaches the splitting exercise based on the business motives/results that a client wants to achieve.

It works as a function of how much time it would take to get something done, and how important it is to the business of the client to get it done. This helps in deciding what’s the most important & urgent requirement, and what can be handled later.

Example: A web-store owner who ships cutlery will have different business rules needed to be implemented, such as:

  1. Customers should be able to pay through different payment options: Credit card, E-wallets, etc.
  2. Every order should automatically create a dossier with shipping information of the customer that can just be printed and attached to the parcel.


Out of these, the more vital need of the business is to be able to accept most payment methods. This ensures that customers wouldn’t be deterred from making a purchase just because their payment method isn’t listed. 
Meanwhile, the slip of the shipping details can easily be created manually.

What is splitting by data Types?

The parameters being accepted and the data types being returned drive the splitting process in this case. Depending on the priority of the data types and parameters that are being handled by the system, the priority of the child-stories is decided.

Thus priority is decided by evaluating which datatype is the most value-deriving in nature and hence most important to the client. 

A story that does similar operation using different data types can be divided into child-stories that individually address each datatype. This way, features can be built-up incrementally to work with more and more kinds of data.

A highly-preferred approach in this splitting strategy is to first integrate data types that are the easiest to process and are used most often, and then with time, build out to include the more complex ones.

Conclusion - Splitting User Stories

We’ve discussed few of the most important & widely used splitting techniques in the industry. You have been presented with some different techniques to make this happen.

It now comes down to you, to decide which method is best for you. Before you go, lets tackle another related topic that has many Agile fans attentions:

Agile User Stories vs Use Cases: Which one is Better?

Agile User Stories vs Use Cases: Which one is Better?

So, Agile User stories vs Use Cases: Which one is better?

Before we answer this, we'll discuss and explain a little bit more about what these approaches entail as well as the difference between the two. First and foremost, User stories are not the same as Use cases

User stories and User cases are not interchangeable. Both have their identified users and both have their own described goals, however, they serve very different purposes.

A User Story largely dwells on the results and benefits of the certain thing you're describing while Use cases are usually more granular and are centered on describing how the entire system will act. 

User stories usually start off pretty similar to Use cases in the sense that they are goal oriented, each has its way of describing how the system is to be used, designed with the user's perspective in mind and uses the businesses natural language.

User Stories In Agile

A User story is basically a small note that records what a user needs or does while they are at work. Each User story usually contains a written short description derived from the user's point of view in their natural language.

The main focus of a User story is to concentrate on the user's needs and not the expected results of the system.

It runs on a 3C's concept. The 3C's is a reference to the three vital aspects of what make up a good User story. These days when people are talking about User stories they're basically referring to a User Story that is made up of these 3 critical components mentioned below.

  • Card: User Stories are usually written as cards. Each card consists of a short sentence that has just enough content to remind all concerned what the stories are all about.
  • Conversation: Continuous conversations between development team members and customers throughout the whole agile software project are how requirements are found and then refined. Important decisions and ideas are usually recorded and discovered during stakeholder meetings.
  • Confirmation: This is the User stories' acceptance criteria. During the requirements discussion, the customers confirm to the analyst under what circumstances and conditions the software would be rejected or accepted.

What is a Use Case

Ivar Jacobson introduced Use Cases more than twenty years ago. Their main goal is to capture the point of view of the user while describing the system's functional requirements. 

This basically means that it describes all the ways the end user wants to use the system. Use cases capture and record all the ways the system and user can interact in order for them to achieve their goals as well as capturing all the variables that could go wrong.

There are various model elements that make up a Use case model system. The most important of them being the Actor, the Use case, and the relationship had between the two.

Use cases normally have detailed specifications. A specification in Use case is a textual description of the systems' functionality. It records Actor-System interaction. This means that it records system responses to user interactions.

The Acceptance Criteria In User Stories

A User story isn't all just about a single sentence affair. An Acceptance Criteria is also drafted by the product owner with the objective of defining User story boundaries as well as the confirmation of when a successful story has been completed and is working as it was intended to. 

Let's take this as your user story example: "As an attendee to the conference, I want to be allowed to register online, so that I can cut down on paperwork and register quickly ". The Acceptance Criteria could probably include:-

  • Registration databases have stored the information found on the form
  • Mandatory fields must be completed before a user can submit their form
  • Spam protection is working
  • Credit card payments can be made
  • Users receiving acknowledgment emails after successfully completing and submitting their forms.

Pros and Cons of User Stories

The Pros: Future of CIO state that a User story is an informal process kick-started by a simple sentence. Those of you that have the desire to add small increments of value, sooner rather than later, in agile, will find user stories to be extremely helpful.

It's not mandatory that the Use story be simple. Using Use stories that operate at a high level will add a little more to your productive planning sessions as well as a different way of adding last-minute functions to your software project.

The Cons: One of the most obvious disadvantages when using User story in Agile is that they usually leave out a ton of details because they rely too much on the conversational method of relaying time and details of development. The documentation is normally not complete upfront which can prove to be very time consuming

Pros and Cons of Use Cases

The Pros: The Agile Machine believes that formalized concepts are slowly phasing out Use cases. Some of the concepts provided when using Use case in agile include; ability to break down problems into subdomains and identifying actors. 

In addition to all this, Boost notes, upfront research that is sometimes required in Use cases can prove to be very helpful to the entire project in general.

The Cons: The fact that Use cases provide such formalized outlines of the project means that they often don't offer much room for project additions and negotiations. This is one of their biggest disadvantages.

Conclusion - User Stories vs Use Cases

All in all, they are both quite impressive. Having knowledge of both these systems may prove invaluable. When you start getting the sense and begin to understand the difference between

Use cases and User stories, you will know what purpose each of them, individually, can serve on your agile project. If your the type that only works with User stories or the one that only uses Use cases, maybe when the next project comes along, after you have completed your planning and risk poker, you can use both of them and see how that works for you.

The better one really depends on what you're working on as well as what you're really planning on achieving.

What is the Agile Methodology discussed in the ISTQB certification?

The Agile methodology comprises a set of values and principles applied in the processes for developing software just like other software development methodologies such as the Waterfall model. The word “agile” refers to the capability of something to move easily and rapidly. This is a major feature of the Agile methodology.


When used, it takes a shorter timeframe to complete a project when compared to other methodologies. Iterations are used in Agile projects to deliver prearranged features. The following information will improve your understanding on what is the Agile methodology discussed in the ISTQB certification.

Key Phases Involved in Agile Methodology

  1. The Concept Phase: During this first step, you and your team analyzes and arranges projects in order of importance. Each concept will require a definition of the business opportunity and how much time it will take to deliver the project.

    Once this information is compiled, you will be able to determine the achievability of each project and know which one is worth working on.

  2. The Inception Phase: Here, you will work on the requirements with the stakeholders. You can create a flow chart that explains how the feature you’re developing should work.

    You then choose people who work on your team and develop a timeline for each activity showing when specific work needs to be completed for the length of the sprint.

  3. The Iteration Phase: The developers and designers start to work on the initial iteration of the project. Their main goal here is to create a working product at the end of the given timeframe. This is just the first iteration as the product will go through quite a number of adjustments.

  4. The Release Phase: To complete the software iteration, the system is tested for errors or malfunctions. The user and system documentation are finalized for everyone to get a clear picture on how the system works and how they can improve it. After this, the iteration is released into production.

  5. The Production Phase: In this phase, your team works at ensuring the system functions smoothly and trains the users how to work with it.

  6. The Retirement Phase: It is in this final step that you move the system from production, more so when you’re ready to replace it with another release.

So What Exactly is an Agile Sprint?

An Agile sprint refers to the specific duration of time during which certain tasks have to be finished and prepared to be reviewed. Sprints usually last for about 10 working days and comprise the following steps:

  • A planning meeting where the team gets together and discusses the mechanisms for the forthcoming work.
  • Designing and developing the product keeping the official guidelines in mind.
  • Testing the results and documenting them.
  • Presenting the product to the client.
  • Gathering feedback from the client and integrating it in the next sprint.

What Does the Agile Scrum Refer To?

The Scrum is a subdivision of the Agile methodology. It is the most commonly used set of practices for Agile development. In simpler terms, it is a framework used to manage processes involved in a project. Scrum is mostly used when developing intricate software through the use of iteration practices.

It is preferred due to the fact that it reduces time and increases your team’s productivity. In addition, Scrum makes allows you to easily adjust to changes in product requirements. It helps you to:

  • Handle change easily.
  • Improve the quality of the finished product.
  • Take control of the project timeline.
  • Give the best estimates while simultaneously using less time to create them.

Scrum is dependent on a team that is self-organizing, such that the entire team will together make decisions on who will be assigned what task. Also, everyone in the team must have the ability to develop a feature from the concept to execution phase.

There are two major roles in the Scrum model; the Scrum Master who is basically the team leader and the Product Owner/PO who is the customer/user.

So what is Agile Design?

When you think about it carefully, agile design refers to the implementation of Agile development principles to the design process. Due to the fact that every designer on your team is different, it is important for you to choose the best techniques that work for you and get accustomed to them as you move on.


Some of these principles include:

  • Involving your clients in every step of the processes: This is the best way for you to ensure that the client gets a clear understanding of what they are working towards as opposed to conventional design processes that work at a creating a perfect final end-product.
  • Compile work from your teams regularly: This will help you to detect bugs or issues that may interfere with the overall product and fix them immediately or note them down to be adjusted in the next iteration.
  • Always Carry Out Tests: Frequent testing will allow your team to identify and solve problems and this will consequently catalyze your team’s creativity.

What Are the Most Common Tools Used in Agile Design?

In order to be successful, designers and developers need to seamlessly work together.
The following are some of the most common collaboration tools and software used in Agile design:

  • Slack: A chat application that keeps your team updated every minute.
  • Justinmind: A prototyping tool for both mobile and web applications.
  • Asana: Assists your teams to plan their projects and organize daily activities through a platform the enables them to track the status of their jobs.
  • Agreedo: Helps your team to plan scrum meetings.
  • ProductPlan: Assists with creating roadmaps which help your team to visualize the strategy.

To sum it up, the Agile Methodology has proven to be the best with regards to using less time in the software development process. Did you enjoy this detailed explanation regarding the Agile Methodology? I chose to cover the areas as presented so as to explain the main components involved in this methodology and in the simplest way possible.

Feel free to leave a comment below with your feedback and if you enjoyed the article, don’t forget to share it with others who would be interested in the subject.

Skip to toolbar