Roles | Project Manager vs. Scrum Master

Project Manager vs. Scrum Master: Key Differences & Similarities
Concise Software | Sep 05, 2019

Who is a project manager?
A project manager is a person in charge of the project timeline, scope, and resources. Their central responsibility is making sure that all these elements meet specified business requirements.
Here are some typical responsibilities of project managers:
Defining the project scope and communicating it to the team
Preparing the schedule for team members
Defining resource requirements for the project
Gathering project requirements
Preparing the project budget
Monitoring the work
Managing relationships with clients and stakeholders
Assuring quality
Ending the project

Who is a Scrum Master?
A Scrum Master is part of the Scrum Team, as defined by the agile methodology framework called Scrum. The Scrum Master is a servant-leader for the Scrum Team. He promotes and supports Scrum as it is defined in the Scrum Guide, and he helps the Team to understand the rules, values, and practices that are a part of this framework. His main goal is to maximize the values created by the Team.

The project manager is responsible for meeting the project objectives; the Scrum Master doesn’t realize this role in the Scrum Team. This responsibility is closer to the Product Owner, whose focus lies on maximizing value from the product. The Scrum Master usually helps the Product Owner in backlog management and product planning — after all, the Scrum Master’s expertise is in the tools and techniques that help teams stay productive and well-organized. The Scrum Master also makes sure that the product domain, scope, and goals are clear to the team.

Project manager vs. Scrum Master: the differences
Consider the ten project management knowledge areas. The Scrum Master contributes to resource, communications, scope, and quality management knowledge areas within the organization. The project manager contributes to all of them.
The Scrum Master follows the Scrum rules and fosters the Scrum framework. The project manager, on the other hand, is free to customize their approach to match the unique needs of the team, department, or the entire organization. They can select the right approach by taking into account the project requirements.
While the project manager prepares a meeting schedule and project communication plan, the Scrum Master facilitates Daily Scrum meetings and other meetings in accordance with the Scrum framework.
The Scrum Master works in small Scrum Teams and is responsible for the performance of this team. Project managers usually handle larger teams and sometimes even multiple project teams. The project manager is responsible for the performance of various project teams.
Project managers prepare the work schedule and assign responsibilities to team members. Scrum Masters coach the team on the Scrum framework and motivate team members to do their best.
While the Scrum Master cares more about maximizing the product value based on user stories, the project manager plans and schedules the project scope, sometimes baselining the budget.
Since these two roles require different skills, project managers usually focus on PMP or Prince2 certifications for project management roles. Scrum Master needs certification from the or from Scrum Alliance.

Project manager vs. Scrum Master: the similarities
They don’t have supreme authority. Project managers have to report to clients and other project stakeholders. Scrum Masters have to report to clients, project stakeholders, and Product Owners.
Both the project manager and Scrum Master communicate with the team, receive feedback, mitigate risks, and ensure greater bonding within a team.
Project managers and Scrum Master are concerned about the team’s performance and always look for ways to help the team improve its efficiency.
The Scrum Master engages with the team for coaching and facilitation of Scrum ceremonies. The project manager also engages with the team, especially for resolving conflicts and issues.
Both roles focus on quality and adhere to industry best practices that ensure it.
They face many challenges and work in demanding industries.
Both roles require years of experience and specific skill sets to succeed.


User Stories | Atlassian Examples

User stories with examples and a template
Atlassian | Undated

User stories are development tasks often expressed as “persona + need + purpose.” 

What are agile user stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

Why create user stories?
User stories serve a number of key benefits:
Stories keep the focus on the user. A to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.

How to write user stories
Consider the following when writing user stories:
Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For whom? If there are multiple end users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Once the user stories are clearly defined, make sure they are visible for the entire team.

User story template and examples
“As a [persona], I [want to], [so that].”

Breaking this down:
As a [persona]“: Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’re missing the point.
So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

Author = Max Rehkopf


Websites | Quality Assurance

Your Complete Guide to Website QA (Quality Assurance) with Free QA Checklist
SEOptimer | Undated

What is website QA? Website QA (Quality Assurance) can be defined as the process of testing a website in order to discover mistakes, errors or oversights that may not have been noted during web development or design before going live. It is also referred to as QA testing. Note that QA begins way earlier, even before development begins. It starts as soon as the requirements for the website are laid out and culminates in testing. Its overarching concern is the quality of the overall site, which goes far beyond just fixing bugs.

How does QA differ from other testing types?
QA is a process, not a one time task.
QA vs user testing
QA vs functional testing
QA vs requirements testing
QA vs design testing

Other testing types:
Regression testing
– evaluating whether making changes in your site affects other parts of the site. It checks whether any changes to the code, for example, breaks the site.
Integration testing – this is testing whether third party services or sources are working as expected when integrated with your site. These services may include APIs.
Performance testing – this tests whether the site can handle traffic spikes and surges. This test may also include how fast the site loads.
There are many more tests that you could do on your QA testing.

Why is it important? Website QA is geared towards ensuring that the web site’s user interface (UI) functions as intended (there are no bugs). It also makes sure that great user experience is achieved. Here are the other benefits of QA testing:
Showcases your brand as reputable.
It could reveal problems that may have dire consequences.
Allows for the delivery of a reliable site.
It ultimately saves the business money and time

How to carry out website QA testing
Factors to consider when designing a QA process flow
Application type
Test specificity
Risk level
Estimated number of users
Tools to use
The platform the site is accessed on

QA best practices
Define the users who will be using the end product.
Follow your checklist for every testing phase or type.
Test using a staging site (a site that simulates the real site).
Schedule the amount of time each testing phase needs to take.
Test as early as possible – test new features as soon as they are added.
Use an agile QA approach (test at the end of different stages of development).
Prioritize bug fixes, depending on how critical they are to your site’s functionality.
Automate where possible, especially the high risk parts of the site. Do not ‘over-automate’, though. Prioritize testing the parts where automation would fit best.
Strive to establish a collaborative approach between your QA team and the design/development team.
Create a site mind map, a visual that will help you see your site’s structure in order to get an idea of the scope of work and identify the parts that you need to prioritize.

What tools can you use for your website QA?
Web Developer Form Filler
Ranorex Webtestit
Window Resizer

Website QA checklist
Functional testing
Performance testing
Security testing
Compatibility testing
Content testing

Use our website QA checklist for your needs, and add to your own checklist and customize it as you see fit.

Author = Jay Kang


User Stories | I.N.V.E.S.T.

The 6 Attributes Of Effective User Stories – INVEST
Kaizenko | Mar 08, 2016

Bill Wake came up with the INVEST acronym to help us remember guidelines for writing effective user stories: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

Independent: As much as possible, try to make sure that stories are not interdependent as this might lead to prioritization and planning problems. Independent is different from logical order of developing things. By independent, we mean story features. For example, let’s say we are supporting payment by credit card and we want to support payment by American Express, Mastercard and Visa. Well if we had a story for MasterCard and another for Visa, then the estimates will depend on which one we do first because implementing the other story will then be relatively straight forward. So we’d want to clarify and have one story represent “providing a primary payment option using VISA”. The other stories can then change to “provide a secondary payment option using American Express”.

Negotiable: A story should be brief. It is not a detailed contract. It’s purpose is to encourage ongoing conversation and scope negotiation between the customer and the developers.

Valuable: A story should provide value to the customer or the user. If a customer cannot think of a value statement, then perhaps we should de-prioritize the story or maybe the work is unnecessary, and we should eliminate it altogether.

Another reason to have a value statement is that value represents why we are building a certain feature. Presenting the team with the Why (value) and not just the What (feature) might trigger different ideas of alternate features that are easier or faster to develop and yet achieve the same goal and deliver the same business value.

Also, because a story is delivering a piece of functionality, the customer can figure out how much this functionality costs and then decide if they still need it.

Finally, remember that not all value is monetary. Mitigating risk is value. So is knowledge learning or acquisition.

Estimatable: Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it. Key factors for estimation are properly sized stories as well as domain knowledge and technical knowledge.

Small: Stories should be small.

Testable: Stories should be testable in order to help determine completeness. A story should have an acceptance criteria. The acceptance criteria should be objective. Avoid using criteria like easy to use, fast or bug free. Try to write criteria that can be measured and tested (ideally automated). For example, test that payment verification responds in 1 second or less at least 95% of the time.

Author = Fadi Stephan


User Stories | Acceptance Criteria

Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices
altexsoft | May 18, 2021

What are the acceptance criteria and their role in projects?
Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems
. They are unique for each user story and define the feature behavior from the end-user’s perspective.
Acceptance criteria are the lowest-level functional requirements
Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.
An important aspect in regard to acceptance criteria is that they have to be defined before the development team starts working on a particular user story. Otherwise, there’s a decent chance the deliverables won’t meet the needs and expectations of a client.

Acceptance criteria main purposes
Making the feature scope more detailed
Describing negative scenarios
Setting communication
Streamlining acceptance testing
Conducting feature evaluations

Acceptance criteria types and structures:

(A) Scenario-oriented acceptance criteria (GWT)
As the name suggests, the scenario-oriented format is the acceptance criteria type that comes in the scenario form and illustrates each criterion. It is approached through the Given/When/Then (GWT) sequence that looks like this:
Given some precondition
When I do some action
Then I expect some result

The acceptance criteria template in this format includes the following statements:
Scenario – the name for the behavior that will be described
Given (a precondition) – the beginning state of the scenario
When (something happens) – the specific action that the user makes
Then (this the result) – the outcome of the action in “When”
And – used to continue any of three previous statements
When combined, these statements cover all actions that a user takes to complete a task and experience the outcome.

Example – User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.
Scenario: Forgot password
Given: The user navigates to the login page
When: The user selects option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password

(B) Rule-oriented acceptance criteria format
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios
Usually, criteria composed using this form look like a simple bullet list.

Example – User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Basic search interface acceptance criteria :
The search field is placed on the top bar
Search starts once the user clicks “Search”
The field contains a placeholder with a grey-colored text: “Where are you going?”
The placeholder disappears once the user starts typing
Search is performed if a user types in a city, hotel name, street, or all combined
Search is in English, French, German, and Ukrainian
The user can’t type more than 200 symbols
The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

Ready-to-use acceptance criteria templates

Roles responsible and how acceptance criteria are created
Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.
There are no strict recommendations to choosing the person responsible for writing the criteria. The client can document them if he or she has ample technical and product documentation knowledge. In this case, the client negotiates the criteria with the team to avoid mutual misunderstandings. Otherwise, the criteria are created by a product owner, business analyst, requirements analyst, or a project manager.

Main challenges and best practices of writing acceptance criteria
Document criteria before development.
Don’t make AC too narrow.
Keep your criteria achievable.
Keep AC measurable and not too broad.
Avoid technical details.
Reach consensus.
Write testable AC.

Follow these tips for guidance on how to phrase your AC.
Write in active voice, first-person.
Avoid negative sentences.
Write simple, concise sentences.

Final word
Don’t neglect the acceptance criteria as they – being simple and approachable – solve multiple problems at once. They document customer expectations, provide an end-user perspective, clarify requirements, prevent ambiguity, and eventually help quality assurance verify if the development goals were met. Regardless of whether you use Agile methods or not, make sure to choose the best format or experiment with your own ones. Different types of user stories and eventually features may require different formats and testing the new ones that work for you is a good practice.

Author = altexsoft


Roles | Project Manager VS Scrum Master

What Is The Difference Between Traditional Project Manager And Scrum Master?
iZenBridge | 04/01/2019

Project Manager [PM]

PM owns the goal of delivering a project. The team assists the PM in delivering the work products of the project. The PM is in charge of the project management processes right from planning to the execution stage. PM is the center of all the action and is a single point of contact for successful delivery of the project.
PMs have the “Project” Mindset. With this mindset, all the key decisions are taken by the PM. The mindset is all about how to deliver the project on time. The teams follows and executes them.
To successfully achieve the project goal, PM must be having project context and knowledge, delegate tasks, update plans, drive multiple status meetings, communicate with stakeholders and focus on process.

Traditional Project Manager
owns the goal of delivery of project.
does all the work right from Planning, prioritizing features, managing dependencies across teams, takes Risks, communicates etc.
is single point of contact for driving the delivery of the project
PM is the center of all the action and is a single point of contact for successful delivery of the project

Scrum Master [SM]

Unlike PM, the SM is not accountable for delivery of the project. SM is grounded in servant leadership and facilitation, the SM roles do not map directly to any deliverables.
The SM owns the goal of making the team accountable for the project. The Team is at the center of all the action. Scrum master takes the back seat, guides the team by demonstrating the best practices of scrum ceremonies, mentors, grooms, coaches, and develops the team into self-organized, self-managed team. SM inculcates the agile mindset, scrum values, and promotes XP Practices into the team in a way that the team sustains delivering the customer value continuously with no compromise on quality.
Team follows “agile manifesto” values and does all the work done by the traditional project manager. Once the teams are fully coached and transformed into high performing self-organized teams, it’s like attaining Nirvana for the agile teams. The Scrum Master makes the team self-organized, shields the team from outside distractions and assists the team in unblocking any impediments, so that the team can achieve its desired goal.

Scrum Master
owns the goal of making the team accountable for the project.
Team follows “agile manifesto” values and does all the work done by the traditional project manager.
guides the team towards delivery of project.
The Team is at the center of all the action. The Scrum master is out of the action and plays a role of facilitator and servant leadership

Article also includes a few other opinions on these roles

Author = Giri Saran


Humor | Quarantine Diaries (excerpt): Videoconferencing with BBC backgrounds

The joy of sets
BBC Archive | Undated

Top of the Pops, Match Of The Day, Fawlty Towers, Absolutely Fabulous, Doctor Who… I guess this is more for your personal calls: change your background to one of these empty sets from classic BBC TV shows.
Over 100 to choose from, different versions of Doctor Who’s Tardis.

Something fun to try at the end of this week, dedicated to Videoconferencing info. Enjoy.

Author = BBC

Empty sets: Science Fiction

Empty sets: Sitcoms

Empty sets: Entertainment

Empty sets: Children’s Television

Empty sets: EastEnders

Sport sets

The joy of sets

Tools | Videoconferencing: Google Meet, alternative to Zoom

As I was tweaking yesterday’s post, I found a new one posted today, covering Google Meet, another free alternative to Zoom. Building a referential on the fly.

How to use Google Meet: Free video conferencing if you don’t love Zoom
c|net | May 07, 2020

(…) Google’s Meet video conferencing service is now free for everyone to use for personal video chats.

(…) Previously available only to organizations using G Suite, Meet is now open to everyone, in a move that puts Google in competition with rival video chat service Zoom.

(…) Meet allows up to 100 participants on a call at once, and includes features such as scheduling, screen sharing and real-time captioning.

(…) Video calls will have a 60-minute cap, but Google said it won’t enforce that cap until after Sept. 30. 

How to use Google Meet, free

Author = Alison DeNisco Rayome

Tools | Videoconferencing: Messenger Rooms, alternative to Zoom

Facebook’s Messenger Rooms video chat app: How to use this Zoom alternative
c|net | May 05, 2020

(…) Facebook users will soon be able to create a video chat room via Facebook or the Messenger app and invite up to 50 people to join a video call — even if they don’t have a Facebook account. There will be no time limits on calls.

Messenger Rooms arrives as some people are looking for an alternative to Zoom, which has faced a number of security and privacy issues in the past two months. (If you are still using Zoom, you can take steps to lock down your meetings and prevent Zoombombing, and learn other hidden tips and tricks).

How to create a Facebook Messenger Room

Author = Alison DeNisco Rayome (c|net)

Tools | Videoconferencing: Zoom, Tips & Tricks

A compilation of reference material to make the best use of Zoom

Zoom: Important Notice: Please begin updating all your clients to Zoom 5.0 now. After May 30, 2020, all Zoom clients on older versions will receive a forced upgrade when trying to join meetings as GCM Encryption will be fully enabled across the Zoom platform.

16 Advanced Zoom Tips for Better Video Meetings
Groove | Undated

Zoom Keyboard Shortcuts
1) Quick Invite = Cmd+I (PC: Alt+I) open invite window
2) Record Meeting = Cmd+Shift+R (PC: Alt+R) / pause/resume = Cmd+Shift+P (PC: Alt+P)
3) Share Screen = Cmd+Shift+S (PC: Alt+Shift+S) / pause/resume = Cmd+Shift+T (PC: Alt+T)
4) Mute Audio = Cmd+Shift+A (PC: Alt+A) mute/unmute
5) Turn Off Video = Cmd+Shift+V (PC: Alt+V)
6) Mute Everyone = ⌘Cmd+Ctrl+M (PC: Alt+M) note: only the meeting host can mute everyone on the call at once

Zoom Settings
7) Always Mute Microphone
8) Always Turn Video Off
9) Display Names
10) Auto-copy Invite URL When Starting a Meeting
11) Enable Shortcuts Outside of Zoom
12) Meeting Reminder (Mobile)
13) Disable Waiting Room
14) Touch Up My Appearance

Zoom Integrations
15) Slack
16) Zapier

Author = Alex Turnbull (Groove)

How to use Zoom like a pro: 13 hidden features to try at your next meeting
c|net | April 28, 2020

  1. Change your background
  2. Mute your audio and turn off your camera by default
  3. Mute and unmute with the space bar
  4. React with emoji on screen
  5. Learn handy keyboard shortcuts
  6. Turn on gallery view
  7. Hide nonvideo participants
  8. Share your screen
  9. Turn on the beauty filter
  10. Record the meeting to your computer
  11. Record a meeting to the cloud
  12. Host a group meeting longer than 40 minutes
  13. Host more than 100 people

Author = Alison DeNisco Rayome (c|net)

Hot Keys and Keyboard Shortcuts for Zoom
Zoom | Undated

Zoom Help Center Reference / Online Manual

Author = Zoom

The complete Zoom guide: From basic help to advanced tricks
ZDNet | April 17, 2020

Zoom 101 = Good introduction with step by step tips and tricks to use Zoom.

Topics covered:

Note: part of a ZDNet Special Feature: Working from Home: The Future of Business is Remote, mentioned on trulySCRUMptious in April 2020
(Direct Link included below)

Author = Charlie Osborne (ZDNet)

ZDNet Special Feature: Working from Home: The Future of Business is Remote
Author= ZDNet

8 Tips for How to Use Zoom Like a Pro
wirecutter | Undated

Beautify (or hide) your face
Pretend you’re on the moon or cosplay as George W. Bush
Prevent embarrassment by silencing desktop notifications
There’s more to screen sharing than PowerPoint presentations
Hosts can (and should) mute attendees
Take advantage of Zoom’s powerful scheduling feature
Keep unwanted guests out of meetings
Finally (and this can’t be said enough), please mute yourself


After re-evaluating our videoconferencing software picks, we can no longer give Zoom our full throated recommendation.

While it has the best balance of features, usability, and value among the major videoconferencing providers, the privacy issues remain a worry until they’ve been satisfactorily addressed. That said, if you’re already using Zoom for casual chats with friends and you’re not divulging sensitive personal info or discussing issues of national security, you’re probably fine to keep using it. Just educate yourself when it comes to the best settings to use before you start a meeting and the best practices for keeping meetings secure.

Author = Ben Keough (wirecutter – A New York Times Company)