Daily Scrum Update Using Scrumboard

The Daily Scrum is one of the most important aspects of the Scrum framework. Scrum’s transparency comes from openly viewable information tools such as the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint.

The Scrumboard usually contains four to five columns to indicate the progress of the estimated tasks for the Sprint:

  1. A ‘Stories’ column for the list of tasks (optional, usually a part of the Prioritized Product Backlog)
  2. A ‘To Do’ column for tasks not yet started
  3. An ‘In Progress’ column for the tasks started but not yet completed
  4. A ‘Testing’ column for tasks completed but in the process of being tested, and
  5. A ‘Done’ column for the tasks that have been completed and successfully tested.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress.

The Scrumboard should preferably be maintained manually on paper or a white board, but can also be maintained electronically in a spreadsheet.

The Scrum Team should change or add to the Scrumboard as required so that the board provides visual information and control about the work going on as agreed and committed by the team. Updating or referring to the Scrumboard during the Daily Scrum keeps the team focused on the tasks that remain and their priorities.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Why Empirical Process Control is Important in SCRUM?

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in Scrum:

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

For more informative articles about Scrum and Agile, visit www.scrumstudy.com

Difference between Waterfall and Agile

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling.

Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods. Agile projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.

As the customer regularly interacts with the team in Agile projects, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish, and this ensures that the team is progressing and the project will be completed on time. However, in Waterfall there is no such interaction as the work is carried out in silos and there is no presentable functionality until the end of the project. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.

However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful. In complex projects, in which the customer is not clear about what the end product will be and, therefore, the end product functionality keeps changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete. The Waterfall method struggles to accommodate such changes.

Agile methodologies require a change in mindset from traditional methods. The central focus has moved from the scope in Waterfall methods to achieving maximum business value in Agile. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Agile, quality and constraints can be altered to achieve the main objective of attaining maximum business value. Agile methods are more successful in the current market, which is marked by unpredictability and volatility. Agile methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

What’s better- Scrum and Agile or Waterfall?

There are lot many ways to develop or code software. Easiest is the one in which no documentation, design or testing is involved. Others describe on how to improve coding, testing etc.

All developers claim that software delivered is better by their method and also is faster with less effort. It sounds really good but everything should have a proof when it comes to software.

Although,Agile methods are not at the peak but its growing and getting very popular every day.

However, it’s difficult to prove on whose method of software development is better as there is no scientific uniform data to compare or methodologies like Agile or Scrum. All the projects depend on the skills and knowledge of the people involved in it, domain used, choices made at every stage, process method.

This comparison is more like comparingcars to trucks where anyone can easily say: that is not a real car and this neither a truck.

We all know that every project of software is different n by its nature software development is exclusive. It is fundamentally true. There are people who still try to differentiate the effectiveness of methods of software development. It has been proved that there are several different methods and most of them were significant in specific situations.

Also, people promote the methods of software development, which many say is nothing but a way of earning more money by many consultants. Small companies of trainers and consultants get created easily with the help of the certifications and eventually they get busy training the delegates of big companies.

It’s always better to take the help when needed moreover nothing wrong in it as it might act as the help you were actually looking out to give the final touch to the project.

Agile is very well known and popular as it givesyou many best practices, focuses on the job to be done, though we should accept it that it doesn’t happen every time. As far as Scrum is considered, a well-judged product owner’s presence will prove it to be the faster and effective than waterfall approach.

Importance of Acceptance Criteria in Scrum

Acceptance criteria define requirements that a User Story must satisfy before being accepted and considered ‘Done’ by the Product Owner. Acceptance criteria are unique to each User Story and are not a substitute for requirements list.
For example, a User Story for creating aticketing website could read:
“As a customer I should be able to add/delete multiple items from the cart before I checkout so that I do not exceed my budget.”
The acceptance criteria for the User Story above could be written as:
·         The shopping cart has to automatically update when a user adds an item.
·         A user can successfully delete/modify the contents of the cart from a single window.
·         Cart items are saved until the user clears its contents or logs out from the website without saving.
It is important for a Product Owner to note that User Stories that fulfill most, but not all, acceptance criteria cannot be accepted as done. Scrum projects operate in time-boxed Sprints, with a dedicated backlog for each Sprint. Often, the last bit of work might be the most complicated aspect of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being done and carried over to the next Sprint, then this could disrupt the progress of the Sprint. Therefore, the done-status is black and white. An item can only either be “done” or “not done.”

Apart from the acceptance criteria, a user story must also fulfill the “Done” criteria. Done criteria differs from acceptance criteria in one key aspect. While acceptance criteria are unique for individual User Stories, done criteria are a set of rules that are applicable to all User Stories. Generic done criteria could include:

  • Review by other team members
  • Complete unit testing of the User Story
  • Completion of quality assurance tests
  • Completion of all documentation related to the User Story
  • All bugs are fixed
  • Successful demo to the stakeholders/ business representatives

Just like with acceptance criteria, all conditions of the generic criteria must be satisfied for the User Story to be considered done.

CompTIA Project+ Certification Exam

CompTIA Project+ certification is an international, vendor-neutral certification that covers the entire project life cycle from initiation and planning through execution, acceptance, and closure. CompTIA Project+ gives project managers the skills necessary to complete projects on time and within budget, and creates a common project management language among project team members. Based on best practices of project management, the exam incorporates universal project management principles, and includes critical soft skills such as conflict resolution, negotiation, communication, team building/leadership, and setting and managing expectations. CompTIA Project+ covers the entire project life cycle, from initiation and planning through execution, acceptance, support and closure. It validates that project managers and team members have the classic project management skills to help them complete projects on time and within budget.

Test Details – CompTIA project+ exam (Exam Code – PK0-003 has a total of 100 questions to be attempted in 90 minutes. The passing score is 710 (on a scale of 100-900). It is presently available in 4 languages – English, Japanese, Korean and Spanish. Recommended Experience for the exam is one year of managing, directing or participating in small- to medium-scale projects, according to CompTIA.

MyITstudy, one of the leading IT training provider, has classroom, online and instructor-led live classes for the CompTIA project+ certification course. It has a dedicated team inside the company which manages only IT training courses and ensures a dedicated focus required to offer consistently high quality IT training to the students. All the MyITstudy instructors are CompTIA certified with an average IT industry work experience of 15+ years and an average professional teaching experience of over 1500 hours.  Besides offering free exam retake, MyITstudy also provides the delegates with a free laptop for every CompTIA course training they undertake with MyITstudy. The laptops are used to conduct hassle free training for the delegates and to provide them with the online lab access which is essential for an IT certification.

Following are the course benefits of attending a CompTIA project+ course:

  • The course fee includes a free laptop.
  • The course fee includes the cost of exam voucher.
  • Students have an adequate lab facility at the training center.
  • We offer an unmatched Free Exam Retake policy.
  • 5-day classroom training is delivered by experienced trainers.
  • High-quality, comprehensive classroom study materials are provided-students are not required to bring anything additional to class.
  • Refreshments are provided during classroom sessions.
  • Instructors provide valuable tips for passing the Project+ exam.
  • Instructors use best-training methodology for classroom teaching.

Core Roles in Scrum

An important feature of SCRUM is little number of roles. These Roles have direct influence on the realization of a project. The SCRUM core roles are believed to be accountable for the production of deliverables which meet the acceptance criteria in every sprintwhich in turn ensures success of the entire project.

The following arethe three principal roles in Scrum:

  1. The Product Owner-is the voice of the business,
  2. The Development Team- that converts ideas into functionality
  3. The Scrum Master -who enables the team and process

The Product Owner 

The product owner is regarded to be the one who has far-sightedness of the project and is accountable for accumulating the requirements and needs to understand the value of the project.

The product owner is also responsible for dealing and listing the product backlog. He is also involved in the planning of the release.

A product Owner is typically the project manager or can also be a business analyst who has technical skills. An efficient product owner is expected to have attributes such as ample technical knowledge, needs to have domain expertize and should be easily accessible to the development team.
The Scrum Master

The Scrum Master has his/her focus on the progress of the process and also is known to guide the scrum team.

The Scrum Master is responsible for planning the sprints and prioritizing the sprint backlog. He/she is also involved in managing development process. The Scrum Master also helps in identifying and eliminating the obstacles that is currently hindering the performance of the team

The Scrum Master is responsible for preparing the burn down chart and helps in unblemished communication among one and all in the project.

The scrum master enables the group to follow the workflow and ensuresthat the tasks in the sprints are completed on time.

A Scrum Master can either be the team leader or act as the project manager. A scrum master is ideally considered to have a good balance of skills such as technical expertise, problem solver, team player and a problem solver.
The Scrum Team

A Scrum team does not mean the typical development team. A scrum team has its own special capabilities.

Stated below are few features of a Scrum team

  1. Cross-functional teams: the team has members from various disciplines in order to help achieve the approved functions.Software engineers, programmers, architects, analysts, system admins, testers etc. could be the members of the teams.
  2. Self-organizing teams: the teams take a call on tasks to be done by whom and how to complete the tasks.
  3. Business representation:  The business representative is as the voice of the customer, and also the voice of change.
  4. Backlog driven: work is done as per the backlog.

The responsibilities of the development team:

  • Achieve sprint goals
  • To prepare self-made goals
  • To organize their time