Scrum Is a Haven for the Mentally Strong

A article at the end of 2013 identified thirteen things mentally strong people avoid and the characteristics they have that motivate their aversions. They still have those characteristics today. A comparison of that list with workplace practices makes it clear that mentally strong people would feel at home and energized in a Scrum environment.

Cheryl Conner, the writer of the Forbes’s piece, starts the list of “the things mentally strong individuals don’t do” with “Waste Time Feeling Sorry for Themselves.” She explains that these people “have learned to take responsibility for their actions and outcomes.” A Scrum Master readily sees several points of correlation. The first is the Sprint Review meeting in which the Scrum Team members demonstrate what has been accomplished during the Sprint to the customer, if possible, and the Product Owner, who speaks for the customer. This provides immediate feedback for the Scrum Team member, who will have that good feeling of having one’s “actions and outcomes” affirmed or will learn directly what must be done to make the outcome acceptable. Taking responsibility to improve or remake a product is easier with clear, direct communication. The mentally strong individual appreciates this.

Another point of correlation is self-organization in Scrum. “An important feature of Scrum is self-organization, which allows the individuals who are actually doing the work to estimate and take ownership of tasks,” according to A Guide to the Scrum Body of Knowledge (SBOK™). Having a real voice in estimating—setting real and achievable expectations—and being able to have ownership of what one is doing is freeing to the mentally strong who “have learned to take responsibility for their actions and outcomes.”

Conner also says that the mentally strong do not “shy away from change,” “fear taking calculated risks,” “make the same mistakes over and over,” “resent other people’s success,” nor “expect immediate results.” She explains that “they apply their energy and time in measured doses and they celebrate each milestone and increment of success on the way.” Scrum embraces change, uses risk assessment and mitigation throughout each project’s iterations, employs a retrospect meeting at the end of each Sprint to learn from mistakes and create actionable items for future Sprints, builds strong team camaraderie and moves forward incrementally to develop high-quality results.

The Scrum workplace is obviously a strong fit for the mentally strong worker and the mentally astute company.

[Jim Pruitt, VMEdu staff writer, contributed to this article]


For more reference visit:

Business Justification in Scrum

One of the basic questions that comes to the mind of a new member in a project, program or portfolio team is ‘why are we doing this project?’ Business justification of the project not only answers this question but also makes the team understand the importance of the project.


Let us now understand what business justification is, especially, in the context of Scrum projects. In simple words, business justification is the reason for undertaking an endeavor and the benefits outweighing the costs and risks. However, there is more to the assessment of business justification of a project.

An important part of establishing business justification is estimation of the project value. Project value is determined by considering various factors such as project reasons, benefits, costs, timescales, risks, dis-benefits, etc. Estimating the project value helps the decision makers make the vital decision such as to continue with the existing project or not. And the Guide to Scrum Body of Knowledge (SBOK) delineates various methods to effectively measure the project value. The project value can be estimated by using various methods such as Return on Investment (ROI), Net Present Value (NPV), Internal Rate of Return (IRR), etc. In a project, business justification is first assessed before project initiation, hence it is important for a team to perform a proper business justification analysis and create a viable Project Vision Statement prior to starting any project. The business justification is then continuously verified throughout the project lifecycle at regular intervals and when significant events occur. This is one of the key advantages of Scrum methodology as there is scope for significant changes in the various aspects of a project during the course of its life cycle leading to loss of expected benefits or increase in costs and risks, etc. The project should not only make business sense at the beginning but also in each and every part of its life cycle. Analysis of business justification helps decision makers in understanding the business need for a change or for a new product or service and the need for moving forward with a project. It also helps the Product Owner to create a Prioritized Product Backlog along with the business expectations of Senior Management & Stakeholder(s).


Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM) for more visit:


Various Aspects of Scrum

Scrum is a framework for collaborative effort of the team on some of the very complex software projects. It is the most widely-used subset of Agile. The Scrum principles are the fundamental guidelines for applying Scrum framework. The Scrum framework drives on the goals of giving utmost business value in least time.

Various Scrum aspects are derived and are very essential to be addressed and managed throughout a Scrum project. Here are the five Scrum aspects as mentioned in the SBOK™ Guide

  • Organization: Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum. Scrum roles fall into two broad categories; Core Roles (which includes Product Owner, Scrum Master, Scrum Team) and Non-core Roles (which includes Stakeholder, Scrum Guidance Body, Vendors, Chief Product Owner, Chief Scrum Master)
  • Business Justification: Business justification in Scrum is based on the concept of Value-driven Delivery. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project.
  • Quality: Quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. The Scrum Guidance Body may also provide guidelines about quality which may be relevant to all Scrum projects in the organization.
  • Change: Every project, regardless of its method or framework used, is exposed to change. Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables. This enables the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.
  • Risk: Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks should be identified, assessed, and responded to basing on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence.

SCRUMstudy certification courses offer a detailed description of all these Scrum aspects. Please visit for more details on SCRUMstudy certifications.

Original URL:

Scrum – Don’t implement it without being trained in it

Imagine you are just about to start on a very important project – big budget, all eyes on the team, the kind of project you dreamed of. The whole team is all geared up and ready to get on with the work. When on the first day of the project, the project manager walks in with a lot of enthusiasm and says – ‘Guys, I just read this article about this really cool methodology called Scrum. Everyone has these daily standup meetings every day, decide what they will be working on, do it, and then meet again the following day. I think we should give it a shot.’

It just got better, didn’t it? A big project and a cool new methodology! Not quite, as is often revealed on so many projects. Admittedly, the dialogue of the project manager was simplified, but essentially, this is how a great methodology is set up for failure. Cut to a week later:

Team member 1: ‘Why do we need to stand around? There are chairs around. We can just sit, right?’

Project manager: ‘That is what the methodology says.”

TM 1: ‘But why?’

Project manager: ‘Something to do about if people stand, meetings are shorter’

TM2: ‘But our meetings typically last for an hour or so and it is so tiring.’

Project manager: ‘We have to discuss so many issues. Obviously it will take time. If it is such a big deal, then you can sit.’

Thus begins a slow, but steady twisting of the tenets of Scrum and the team embarks on a slippery slope. As the team now begins to sit during ‘Daily Stand Ups’, the meetings increase in length from 1 hour to 1.5 hours, and sometimes stretching to 2 hours. With less time available for actual work, tensions increase. Team members start questioning the need to meet on a daily basis when on earlier projects they met once a week and things were more or less fine. Then from ‘Daily Stand Ups’, the format changes to ‘Alternate Day Sit Downs’. This affects coordination and as the gap increases between meetings, the meetings start taking a bit longer, or issues increase.

Slowly, other changes start taking place – the whiteboard where tasks were updated in the first week stop being used by team members. Instead, they revert to sending email updates. The project manager, not realizing the critical importance of each of these tenets of Scrum, not trained in Scrum methods and never having practiced Scrum, also starts questioning himself and accepts these changes. He keeps a track of ‘To be done, In Process and Completed’, but only at his desk. Other team members start to become more confused.

Now as the team had dedicated itself to Scrum in the beginning, switching to alternate traditional project management methods in the middle of the project leads to an even bigger mess. End result – a poorly managed project which started off with good intentions of using Scrum as a methodology, but failed because of lack of understanding of Scrum.

Scrum is a simple methodology but needs training in Scrum and guidance for first time users. Without it, critical elements end up getting twisted and the project heads towards failure.

Moral of the story – Scrum training is not optional. If you want to get the best out of it, get expert help in the beginning and only after thorough training, should you use it at work.

Acknowledgement: The content is borrowed from

original blog url: