Essential Characteristics of SCRUM Team

In a Scrum project, it is the Scrum Team members who are responsible for delivering the desired product or service and not the Scrum. Hence, we should be careful in forming the Scrum Teams.

“The Scrum Team is sometimes referred to as Development Team since they are responsible for developing the product, service or other results. It consists of a group of individuals who the user stories in the Sprint Backlog to create deliverables for the project”. – SBOK 2013 Edition.

The essential characteristics of a Scrum Team for delivering the desired project results are described below:

Self-Organized: The scrum team members are motivated individuals who do not wait for their superiors to assign the tasks. They take the responsibility, share the risk, take decision, and work collectively towards a common goal.

Empowered: The Scrum Team or the development team is supplied with the required resources to deliver the desired products or services along with the authority to take the decisions. If the team has only the responsibility but no authority to take decisions, the continuous/iterative development is difficult.

Collaboration: Project management is a shared value creation process with teams working and interacting together to deliver greatest value. The scrum team should share the knowledge, ideas, risk and responsibilities, and work in harmony with the team members to deliver desired results.

Shared Goal: The individuals within the team should work collectively towards a common goal. The team goal should superimpose their individual goals like growth, appraisal, and money.    

Optimum Size: A small Scrum team may not have the required skill to develop the product or service and a large Scrum team may spoil the work as the collaboration within the team will be difficult. As defined in the SBOK, the optimum size of the Scrum team should be six to ten. This will ensure that, the Scrum team is large enough to possess necessary skills to deliver the project and small enough to collaborate.

Diverse Skills: The Scrum Team should collectively possess the necessary skills to deliver the project deliverables. During scrum team formation the team members should be selected keeping in mind the skills required to deliver the project deliverables.

Collocated: It is advised to form a Scrum team with the members collocated. This ensures collaboration and coordination within the team members.

To know more, please visit: www.scrumstudy.com

All About Agile Testing

Coding and testing stages are not isolated ones but well integrated ones in Agile development. The development toward every user story commences through written business-interfacing experiments that enables the team the ‘what part’ regarding coding and also the juncture when the tasks are being completed with.

Professionals in the field of testing, analysis and development interface with stakeholders from the business side for extracting instances of preferred and unwanted manners for every single user story and aspect, and then transforming them into tests which are executable. This is known as Acceptance Test-Driven Development (ATDD) or Specification by Example. The team which is responsible for development will then work in partnership with their customers to choose the specific user story aligning customer expectations apropos the delivery part. User stories will be corroborated upon cracking the different functional, automated functional and manual probing tests.

Time is an important element which should be made inclusive for the whole activities related with testing toward user story estimates. This can include automated testing and manual probing testing. Inexperienced Scrum teams frequently and habitually over promise or goes overboard with their commitment part in terms of extra work planning compared to what they could feasibly do. Testing then gets hard-pressed in the end in the absence of features, due to this undesirable characteristic of the team simply because of the arrival of sprint on the last day. The result – mass demise of user stories hauled from one iteration to the subsequent one without the testing professionals being able to conduct their tests.

Focusing on completing each story at a specified time is a good way to handle this problem.

Necessary role inclusion for comprehending the various customer requirements and delivering good quality oriented software is a benefit that Agile teams possess inherently. Agile teams find the much needed opportunity through their varied experiences and assortment of abilities which help them in traversing different approaches toward supporting business participants in outlining their requirements. They are able to do it through tangible examples provided to the stakeholders and then interpreting the same into experiments certifying the ‘done part’ aimed at every user story along with their features.

Customers are pleased with the outcome pertaining to as an effort of the team – interacting and coordinating with the business teams, taking out the much needed time to plan for evidencing the aspects are done with as per requirements outlined. Newer Agile teams must pool in time to search for different means to comprehend the requisites of customers so that they can interpret those requisites into well conducted experiments which will outline software development. That will bring in maturity in terms of experience and doing things in a speedy manner efficiently and effectively.

To know more, please visit : www.scrumstudy.com

What is Planning Poker?

Planning poker is combination of analogy, expert opinion, and disaggregation in a fun way so that it will result quick and reliable estimates. All the team members are included in planning poker. On any agile project, you will have typically ten team members or less. If it does, the team can be split in twos. Then estimation is done independently by each team. The PO participates in planning poker but he or she doesn’t estimate.

At the beginning, each team member is handed deck of cards. All the cards are marked with a valid estimation number. Each member will be given a deck that reads a number series. The most popular of these estimation numbers are Fibonacci numbers. (1,2,3,5 ,8,13,2, 34,55 and so on). The cards are prepared before the planning poker meeting.

Then a moderator describes each of the user stories or theme that team is planning to estimate. Though generally the product owner acts as a Moderator, anyone can be a moderator. No special privilege or role is associated with the moderator. The product owner will answer all questions that the team members have.

The goal of estimation is to be somewhere on the left of the actual effort line. Important thing to remember is that this process is not about deriving an estimate that will resist all future inspection.

After all the queries are resolved, each team member selects a card that represents their estimation. Each estimator has to make a selection before Cards can be visible to everyone. Cards are kept private until everyone has estimated. Then the cards are turned over at the same time.
Then, all cards are instantaneously spun over and displayed so that all estimators can see each estimate. Chances are that these estimates will differ significantly. In that case, the high and low estimators will explain their estimates. The focus of this process is not to attack these estimators but to learn on what basis these estimations were assigned.

After this discussion, each team member will re-estimate by selecting a card. The earlier mentioned process will be followed again. Chances are that the estimates will meet by the subsequent round. Continue to repeat the process until all the estimators converge on a single estimate that can be used for the story. Very rarely it takes more than three rounds. Continue this process until estimates are moving closer together and they everyone converges on a single estimate.

To know more please visit: www.scrumstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

  • Efficient development process
  • Less overheads
  • High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To know more, please visit : www.scrumstudy.com

All about Agile Methodologies

The term “agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, agile as a quality should therefore be a good thing to aim for. Agile project management specifically, involves being adaptive during the creation of a product, service, or other result.

A number of Agile methodologies originated and gained traction in the 1990’s and the early 2000’s. Here are the various popular Agile methodologies being used.

Lean Kanban: Lean concept optimizes an organization’s system to produce valuable results based on its resources, needs, and alternatives while reducing waste. Kanban literally means a “signboard” or “billboard” and it espouses the use of visual aids to assist and track production.

Extreme Programming (XP): Originated in Chrysler Corporation, gained traction in the 1990′s. XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.

Crystal Methods: Introduced by Alistair Cockburn in the early 1990s, Crystal methods have four roles—executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility.

Dynamic Systems Development Methods (DSMD): This framework was initially published in 1995 and is administered by the DSDM Consortium. DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into “Must have,” “Should have,” “Could have,” and “Won’t have” categories

Feature Driven Development (FDD): Introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks’ time. FDD has two core principles—software development is a human activity and software development is a client-valued functionality.

Test Driven Development (TDD): Also known as Test-First Development, and was introduced by Kent Beck, one of the creators of Extreme Programming (XP). It is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.

Adaptive Software Development (ASD): This method grew out of the rapid application development work by Jim Highsmith and Sam Bayer. The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.

Agile Unified Process (AUP): Evolved from IBM’s Rational Unified Process and developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.

Domain-Driven Design (DDD): This approach was meant for handling complex designs with implementation linked to an evolving model. It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain.

All these methods of Agile differ from each other in a variety of aspects but their commonality stems from their adherence to The Agile Manifesto.

To know more, please visit : www.scrumstudy.com

Who is a Product Owner?

Before we read about how to be an effective product owner, let us first understand who a product owner is and what he/she does.  A product owner is not a separate title but is a role that can be performed by a business analyst or even a representative of an end user.

A product owner is a stakeholder who acts as an interface between the business representatives and the project team. A product owner understands the business requirements and communicates it to the team for development on behalf of the customer. A product owner is responsible for creating Prioritized Product Backlog, attending daily standup meetings, and steering the development process successfully to meet the customer’s requirements. The product owner communicates the progress of the team to the sponsor and key stakeholders. He or she also continuously refines product requirements. It is also important that a product owner has  good business sense which is important while prioritizing user stories based on cost and functionality.

A product owner must be actively involved-

The test of an effective product owner is how well he/she balances the expectations of business representatives and capability of the team to deliver. There are several ways a product owner can be more effective. A common mistake product owners make is not committing enough time to understand the requirements of the Scrum Team. Product owners should be as hands-on as possible and schedule sufficient time to holding estimation workshops, planning sprints, and providing feedback for the team.

An empowered product owner nurtures an empowered team-

Customers most often expect more value to be delivered than what the team  is capable of delivering or might suggest several changes that can slowdown the speed of the development team. A product owner supports his team by managing customer’s expectations so that workflow is not affected due to unreasonable expectations. A product owner allows the team to estimate the effort required to complete the product backlog items identified for a particular sprint. At the same time, a product owner motivates the team to deliver the product backlog items committed fora sprint on time.

Technical knowledge is essential-

It is also important that product owners have some technical knowledge, though he/she does not necessarily have to be a developer themselves. Since, they will be interacting with the team on a regular basis, having a technical background can serve well while resolving issues. Technical knowledge can also help a product owner bridge the gap between technical and business aspects of a project while liaising with developers and business representatives.

 To know more, please visit : www.scrumstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

  • Efficient development process
  • Less overheads
  • High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

 To know more, please visit : www.scrumstudy.com