The QuickScrum community offers a single, common platform for all Scrum people to meet, talk about, and understand Scrum. The community offers endless possibilities for Scrum professionals, coaches, and trainers to find business opportunities. Scrum professionals can participate in events, coaches can hold workshops and share knowledge through articles and videos, companies can post Scrum job requirements, while Scrum beginners can learn Scrum from the vast knowledge base.
Wednesday 28 May 2014
Thursday 15 May 2014
Tuesday 6 May 2014
how to use quickscrum?- Quickscrum user guide
The QuickScrum tool at www.QuickScrum.com is a powerful, easy to use, and versatile web based scrum tool application centered upon Scrum framework. Discover how to set up dynamic projects, allocate project resources, design and plan your projects, utilize feature rich management tools in your ongoing projects, deliver time-bound projects, and generate higher profit margins.
"Please visit http://www.quickscrum.com to Free download the Quickscrum tool"
Wednesday 23 April 2014
Seven Unique Ways To Breath In New Life In Your Sprint Retrospectives
Sprint
retrospectives are an important part of scrum methodology. For Agile
practitioners, retrospectives hold a special significance, and offer an insight
into the self-learning capabilities supported by scrum.
The primary
objectives of a sprint retrospective meeting are:
· Display the user stories to the stakeholders, which
have been developed by the team during the daily sprints
· Have the user stories accepted by the investors as
“shippable”
· Discuss and review the entire sprint, and analyze it
to find how the sprinting process can be improved upon
· Find what lessons can be learnt from the sprint, and
how the team can benefit from prior findings and experiences
One of the issues
faced by the scrum team is the team members end up discussing the same issues
and problems in most of the retrospective meetings. The team feels it is
discussing the same topics again-and-again, and therefore it is redundant to
hold retrospectives. In all aspects, the retrospectives seem to be going
“stale” and the team might be just holding it because scrum advocates it. The
learning and self correction process stops in such cases, and the retrospective
loses its importance and functionality.
So how can you pump
in new life in the retrospectives? A few pointers may help you improve your
meetings.
1. Rotating the
leadership
Instead of the scrum master facilitating the meeting, invite the team members to temporarily assume
the role of a scrum master and conduct the meeting. Each member takes turns and
facilitates the meeting in his or her own particular way and manner. The
members can be asked to experiment with newer adaptations and ways of holding
the meeting.
2. Changing the
questions
The two standard
questions most commonly asked during the meeting are:
1. What did we do well this time?
2. What can be possibly improved upon in the next sprint?
Instead, try asking
the question:
· What actually happened during the sprints, and how did
it occur?
Individuals tend to
look at things from their own perspectives, and at times, they might fail to
comprehend the true situation if they are forced to look at issues from a
different point of view which they are not familiar with. Asking questions
which they find easy to answer can go a long way in making the retrospective
more interesting and useful.
3. Varying the
process
Each scrum team has
its own method of conducting the meeting. While some teams prefer group
discussions during the retrospectives, a few of the teams follow the
traditional pattern of having one member demonstrate his or her work to the
stakeholders. Whichever process you follow, try to change it by including
variations into the meeting pattern. A recommended method is to use histograms
indicating member satisfaction levels. The survey can be conducted anonymously
and the findings presented to the entire team. Suggestions can be availed from
the team members as to what new aspects ought to be incorporated to make the
meeting interesting.
4. Thinking about
unique perspectives
Individuals and
people who are not directly connected with the scrum project, but are still
attached to the project somehow can be invited to attend the meeting. Vendors
and system deployment personnel have different insights to offer since they are
directly connected with the market and have a “working knowledge” about
consumer psychology and requirements. Their participation can help the scrum
team to avail a broader perspective regarding how the development of user
stories should be ideally carried out.
5. Changing the
focus
Every team has a
certain focal point, which it concentrates upon while developing the project.
Switching the focus can also prompt the team to come up with new ideas about
how the scrum process can be improved upon. If the team is concentrating too
much upon the engineering practices, the focus could be changed to
collaborative working and solving technical issues by sharing out the problems.Read more on http://blog.quickscrum.com/post/2014/04/09/Seven-Unique-Ways-To-Breath-In-New-Life-In-Your-Sprint-Retrospectives.aspx
Tuesday 22 April 2014
Monday 7 April 2014
An Overview Of Scrum Methodology
Scrum is a unique framework
specially designed to build a versatile product. The framework supports a
dynamic design, which allows the features and functionalities linked with the
product to be changed, along with the real time changes occurring in the
ongoing market conditions. Generally, a scrum project is started when the
stakeholders or the investors desire to develop a product for marketing and
selling purposes.
Scrum roles
Scrum is basically a
team process. There are three important roles in scrum:
· The Product Owner
Responsible for the work to be done in the scrum
project.
Plays the servant-leader role, ensures that scrum is
properly implemented in the project, and acts as a facilitator.
· The development team members
Undertakes the product development in the form of
sprints and actually gives “birth” to the product.
Daily sprints
A sprint is the
fundamental unit of developing the product in scrum methodology. Actually, the entire product is developed in
short bursts of development activity known as “sprints”. Each sprint generally
lasts for two weeks. It can, however, extend up to four weeks if required, but
in practice it generally lasts for only two weeks. A fully functional, or a
“shippable” product feature or functionality is delivered at the end of each
sprint.
Scrum artifacts
or objects
Scrum includes three
important artifacts which facilitate the scrum
process. They are:
· The Product Backlog
It consists of the user stories, or the list of features and functionalities which
actually define the entire product to be developed.
· The Sprint Backlog
A certain portion, or a subset of the product backlog,
is transferred to the sprint backlog for development purposes during the sprint.
· The Product Increment
It constitutes the list of features and
functionalities which have been developed successfully by the development team,
and is ready for “shipping”.
Scrum meetings
Scrum also requires
five team activities or meetings, which are:
· Product Backlog Refinement
The meeting includes updating the product backlog
items or the user stories with the latest updates and feedback availed from the
stakeholders, and resetting the priority of the backlog items on the basis of
their importance.
· Sprint Planning
Scheduled just before a sprint is to be carried out, the
meeting is used to plan which tasks should be taken up for development by the
team, and to clear the doubts or issues concerning the development.
· Daily Scrum
The meeting is held just before the sprint commences
for the particular day. The purpose is to discuss three important questions
associated with daily sprinting:
-
What was done
yesterday?
-
What is to be
done today?
-
Are there any
difficulties?
· Sprint Review
Once a sprint is carried out, the product owner
compares the user stories developed by the team, whether they fulfill the
acceptance criteria. The review functions as a “learning” activity, and the
team uses the prior experience to avoid potential pitfalls from occurring in
the future sprints.
· Sprint Retrospective
Once the development is carried out in sprints, and
the product owner accepts the tasks as “Done”, it is required to demonstrate
the successfully completed user stories to the stakeholders and the end users.
The retrospective also helps to obtain a feedback from the individuals who are
actually going to use the product.
Thursday 3 April 2014
Agile Values in Scrum: The Important Principles and Values of Scrum Explained
Scrum is perhaps the best known Agile method of implementing
successful projects. Scrum projects complete on time, and result into higher
ROI for the stakeholders. This makes Scrum an ideal, and the most preferred
choice while implementing projects, in which the product definition is liable
to change with the changing market conditions. The Agile values and principles
apply to scrum.
Individuals and
interactions more important than processes
Scrum, just like other Agile frameworks, relies much upon putting
trust in teams and individuals connected with the project. The manner in which
the team interacts is important. The team should take a proactive interest in
determining what is to be done, and figure out how to achieve the aims and
objectives associated with the project. Self correction and self learning is an
integral part of scrum methodology, and the team should put in efforts to
identify potential issues and problems which can act as impediments and hamper
the project. The individuals should also take the responsibility to resolve the
issues – they can take the help of the scrum master or the product owner as and
when required, since these individuals are usually senior members, and have the
required knowledge, as we as the expertise to find a way out and solve the
problematic issues. For issues concerning the stakeholders and the investors,
the product owner should take a proactive approach in availing the
clarifications regarding the acceptance criteria, and guide the team in proceeding
with the user stories. In scrum, it is essential that the team feels
responsible, and undertake the responsibilities in a proactive manner.
Working and shippable software
takes precedence over documentation and marketing concerns
The main purpose and objective of scrum is to produce shippable
products through iterations know as sprints. The entire development of the
product occurs in sprints. At the end of each sprint, the product owner
verifies the quality of the development carried out by the team, and adjudges
the completed user stories, whether they comply with the acceptance criteria.
It is imperative that sprints deliver shippable products which fulfill the
stakeholder’s vision of a successful marketable product. The documentation
required to “manufacture” the product, such as the project analysis report,
project design, testing and documentation of the results, creating user manuals
and technical specifications etc. are important too, but the actual development
through the sprints, and churning out shippable products at the end of sprints
is more important and precedes the documentation associated with the
development.
Collaborating with the customers
more important than contracts and legal documentations
The product owner is the main entity which functions as the main point
of contact between the team and the stakeholders, as well as the end users of
the product. The product owner collaborates with the team, and determines what
needs to be done next to make the project a distinct success. A primary
responsibility is to ensure that the product maintains the highest possible
market value at all times, even while it is being developed. This is the most
critical aspect of scrum.
Transparency and taking
proper decisions at the right time and the right manner
Scrum stresses
heavily upon transparency and sharing information. The entire scrum process is
designed to facilitate the flow of information and increase the transparency.
Each team member should have access to the required information. They should
have access to proper data and important information, so they can make informed
decisions and fulfill their responsibilities in a proper and effective manner.
Each aspect associated with the scrum process – including the product backlog
and user stories – should be made available at all times so that the product
increment through sprints is availed as per production plan and schedule.Source:- http://computersight.com/programming/agile-values-in-scrum-the-important-principles-and-values-of-scrum-explained/
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Why Certain Businesses Fail To Benefit From Scrum – Part 1
Scrum may be difficult to understand and follow
Despite the fact
that scrum framework helps to provide solutions for the drawbacks prevailing in
traditional project management methodologies, in many cases, the company
implementing scrum for the first time may face certain issues associated with
scrum itself. Scrum methodology is highly adaptable and powerful. It can cater
to changing market conditions, and successfully incorporate the changes within
the product development cycle, even while the product is currently being
developed. There are several advantages, which makes Agile scrum a much desired
development methodology. However, implementing scrum in a successful manner can
prove to be very challenging for first timers. The impediments faced are generally
related to the transition process, as the company starts migrating from its
current development methodology to scrum. For majority of people new to scrum, the
environment may appear to be complex, rigid, and difficult to understand and
follow. This is a misconception since scrum can be almost everything but not rigid
in the truest sense. In the initial stage, the team may find it difficult to
understand how scrum works, and what kind of roles the product owner and scrum master play while implementing scrum. In addition, there are certain artifacts
or objects such as the product backlog and the sprint backlog which figure
prominently in scrum. Moreover, scrum events such as the daily sprint meeting,
sprint planning meeting, sprint retrospective meeting, and the sprint review
meeting may confuse novices why they exist, or are needed in the first place.
Scrum can be quite different when compared to traditional waterfall project
development methods, and people often start developing a negative attitude towards
it simply because they fail to understand it.
Not getting the desired results out of scrum
implementation
A company or a business
may decide to implement scrum to reduce the project turnaround time or increase
the productivity and the ROI. There is always a reason why an ongoing process
flow may be required to be replaced by a new one by the business owners. The
management and stakeholders may have “heard” about the obvious benefits of
using scrum, and how their business can possibly benefit from them. The
management personnel may have high expectations, and might even plan their
marketing goals and objective keeping in mind the benefits availed by
implementing scrum in their ongoing projects. However, in many cases, due to
various reasons scrum implementation may fail to produce the desired results
for the particular business, and the entire project may go askew with no clear
indication as to in which direction it is heading for. The reasons may be many
and varied. It is important to know what they are if scrum is to be implemented
successfully.
· Improper
communication channels and feedback
Broken feedback channels and improper communication
processes primarily lead to a void in the learning process which is so very
important while implementing scrum. A major issue is the lack of feedback
availed during the scrum meetings and important information not being transmitted
to the team members in the correct manner, or at the correct time. In scrum,
the entire project is developed in short bursts of development activity called
sprints. Sprints are to be conducted on a daily basis. The daily stand up or
the daily scrum meeting precedes the sprint activity. Three important questions
are to be answered during the meeting. The product increment during the daily
sprint can be affected by the answers availed during the stand up. After the
entire sprint is over, a sprint review meeting is held to evaluate the
development carried out by the team. The product owner and the scrum master
evaluate the entire sprint during the review, and efforts are made to generate
new findings based upon prior experiences. The findings need to be conveyed to
the team.
Result
When the communication channel fails due to some
reason and proper feedback is not transmitted to the team members, they may
start with a new sprint and repeat the same mistakes they made in the prior
sprint. Scrum supports self-learning and self-correction activities which are
possible only when a proper communication channel is set in place, and feedback
is made available to the entire team. If the team members do not receive any feedback
or communications from the concerned personnel, they may proceed with future
activities without any definite aim or objective. This can be disastrous for scrum because
everything is planned, and each activity is carefully regulated in scrum. The
team members fail to perform in the correct manner and the entire project
suffers as a consequence.
· Organization
lacks sufficient scrum knowledge and experience
Project managers are more used to traditional
waterfall methods and are familiar with their process flow. Scrum is very
different, and the framework should be understood in depth before it can be
used or implemented in any particular way or manner. It is essential that the
entire team be educated in scrum and knows how it works. The team members
should be well apprised about the importance of the scrum artifacts and the
purpose of the meetings. They should be made aware about the importance of
sharing information in scrum and collaborating with other team members. At
times, the team may not be clear about how a scrum meeting should be ideally
conducted, and what information ought to be availed from it. A lack of clear
purpose may render the entire meeting as useless. The team members may fail to
deliver productivity in a scheduled or effective manner. The entire scrum
process could be hampered.Read more on http://blog.quickscrum.com/post/2014/03/31/Why-Certain-Businesses-Fail-To-Benefit-From-Scrum-%E2%80%93-Part-1.aspx
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Wednesday 2 April 2014
The Core Role and Responsibilities of a Product Owner in Scrum
One of the commonest mistakes that
people make while considering the product owner’s role in scrum is to consider
him or her as either actually owning the product, or functioning as a decision
maker while developing the product for the stakeholders. This is far from true,
since the product owner is actually employed by the stakeholders to represent
their interests while scrum is implemented in a project. A product owner can
own a product, but is not necessarily its owner in most cases.
The core job of the product owner, or
rather the main responsibility, is to:
· Figure out how to “make” the product
· Ensure that the sprints are successfully completed
during the project
· Shippable products are delivered at the end of sprints
· Ensure that the scrum project is successfully
completed
The product owner’s job is a difficult
one, and a full-time one.
The
product owner as the core determinant of a successfully completed scrum project
It is essential to
deliver value, and the scrum method requires an efficient, reliable, and an accurate
mechanism, which can help to determine the product vision and create an
effective pipeline which has the capability of distilling the product vision
into shippable, concrete, and deliverable product backlog items that can successfully
demonstrate the tangible benefits as a part of the longer project vision. It is
because of this reason that the role of a product owner becomes a very
important one while implementing scrum.
While the product owner can participate
in each Scrum ritual, his or her main function, parallel to that of the scrum master,
is to act as a facilitator for the entire team, and be available when problems
and issues arise in the project. The main tasks of a product owner are:
· Envisioning the product and facilitating its
development
· Creating an iterative or sprint release strategy which
can incorporate the changing market conditions and product requirements
· Distilling the high-level product related requirements
into developable and deliverable user stories linked with acceptance criteria
· Prioritizing the product backlog
· Communicating difficult and complex system
architecture issues to the clients
· Negotiating all client-sided disputes and concerns
associated with the product design, development, and user story priorities
Responsibilities
of a product owner
The person is mainly responsible for:
· Representing the interests of, and acting as the voice
of stakeholders and customers
· Understanding project profitability and delivering high
ROI
· Managing the stakeholders
· Maintaining communications and promoting collaboration
amongst the team members
· Undertaking on-the-spot tactical decisions and
ensuring that the product development cycle is not affected
· Participating in the release meetings and planning
· Writing effective user stories
· Maintaining and updating the product backlog
· Helping the team in estimating the development time
for each scrum scenario
· Participating in the sprint review meetings, accepting
the user stories as “Done”, and providing effectual feedback
· Monitoring the project progress and suggesting constant
adjustments based upon important strategic objectives
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Tuesday 1 April 2014
Norms for Holding Effective and Fruitful Scrum Meetings
Many types of
meetings are held while scrum is implanted in a project. Right from sprint planning meeting to the sprint review and the sprint retrospective, other
non-conventional meetings can also be arranged in scrum as and when needed to
fulfill specific objectives. Following
certain norms can help to effective and fruitful meetings.
· Scheduling
the meeting
The best way to schedule a meeting is to consider all
the information that needs to be conveyed during the meeting, and assign a
proper time and duration for it. Do not try to cram in too many topics so that
enough time is not allotted for discussing each topic during the meeting.
Ideally, the meeting should last for approximately 30 minutes, so work out an
agenda that fits into the time schedule. If the topics to be discussed are
more, hold a separate meeting to discuss them. This is very important, since
the team members need time to absorb the discussion, and remain perceptive to
the plan of action decided for each topic in the agenda at the end of the
meeting.
The time to hold the meeting should be properly
selected too. Choose the time, which is most convenient to all. Ideally, the
meeting should be held around 9 AM when everyone is fresh and about to start
their day, or if that is not possible, than around 3 PM when everyone has taken
the lunch and people are not feeling groggy immediately after having it.
· Members
attending the meeting
Work out the list of attendees who are going to remain
present for the meeting. It is mandatory for the product owner and the scrum
master to attend the meeting since they play a center role in scrum implementation. Invite only those members who are associated with the topics
included in the agenda, and who need to carry out some plan of action based
upon the discussions carried out during the meeting. Other members, who are not
concerned, or who have no connection with the agenda topics should not be
invited so the meeting place is not cluttered up with too many individuals.
When the members are less, it becomes possible to have one-to-one discussion,
which is more meaningful and effective.
· Creating and
distributing the agenda
Make sure that a proper agenda is created that
includes all-important topics. Once the agenda is prepared, send it, or
distribute to the concerned individuals well in time so they have enough time to
prepare for the meeting. Each attendee should prepare a list of queries or
issues concerning his or her work, and present it to the audience during the
meeting. If the participants are well prepared, it leads to more fruitful and
productive meetings.
· Conducting the
meeting in the proper manner
Start your meeting on time. It is advisable not to
wait for participants if they do not make it on time. It is essential to convey
a message that the purpose and intent of the meeting is important, and should
not be trifled with. The meeting should also not be taken lightly by the
attendees. Some organizations even levy a certain penalty if the participants
do not show up on time.
Another aspect is regarding the discussions to be
carried out during the meeting – they should be focused and topic centric. Make
sure, only those topics relevant to the agenda are discussed, and the meeting
is not emphasized with other trivial or non-related discussions. Utilize the
meeting time in a productive way.Read more on https://www.apsense.com/article/norms-for-holding-effective-and-fruitful-scrum-meetings.html
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Monday 31 March 2014
All about How To Hold Conventional And Non-Conventional Scrum Meetings
In many ways, scrum
is all about meetings. Once the product backlog
is created by the product owner, the
meetings starts, and keeps on occurring until the entire project is completed.
While some of the meetings such as the sprint
planning, sprint review, and the sprint retrospective are “planned”
meetings, and the scrum guide lays down clear guidelines as to how they should
be conducted and what should be availed from them, it may be required to hold
special meetings as and when needed to streamline the scrum process. The scrum guide does not mention anything
about non-standardized meetings, or those which have been called impromptu. It
is important to plan and organize such meetings to make them effective in
scrum.
1.
Meet only if required
First and foremost, if the information can be conveyed
through a memo, emails, or a small presentation, don’t conduct the meeting. One
of the key management strategies is to identify the nature and requirement of
conveying the information to team members. If the nature of information is
“simplex” i.e. information needs to be conveyed only “one way”, a lot of time
can be saved by just sending a memo. Typically, the scrum master or the product owner may need to brief up the team
members regarding the feedback availed from the stakeholders, or just let the
team know about the time a particular meeting is scheduled. In such instances,
it is not required to hold a special meeting to convey “one way” information
since a feedback or further discussion is not expected or required with respect
to the message conveyed.
2.
Set up clear objectives for the meeting
If a meeting is supposed to be held, it should have an
objective! It is meaningless to conduct meetings where objectives are not
clearly explained and the team does not have any idea why the meeting is called
for, or what is planned to be done in the meeting. A proper agenda should be
created beforehand and conveyed to the team well in advance so the team knows
why the meeting has been called, and what is going to be discussed in it.
3.
Instruct the members to prepare for the meeting
If you find it necessary to hold the meeting, and have
prepared an agenda to explain what you plan to discuss in the meeting, it is
recommended you instruct or inform the team members how they ought to prepare
for the meeting. Ideally, a list should be prepared explaining what is expected
from the team member, and what activities the particular member should carry
out before attending the meeting. If you have team members belonging to
specific groups depending upon their area of work and specialization, you could
prepare a common list of instructions stating what and how each member in the
group should do to ensure their participation in the meeting is a positive
one.
4.
Prepare a plan of action
Now that you have done everything to make your meeting
a successful one, it is important you achieve the objective of holding your
meeting in the first place. It is important to inform the team members what
they are expected to do once the meeting is completed. More than often, people
attend meetings and simply forget about what was discussed and whether the
objective of holding the meeting was satisfied once the meeting is over. The
reason why this happens is there is no “Call-to-action” linked with the particular
meeting. Each member should know that he or she is supposed to do to complement
the meeting, and ensure its objectives are properly fulfilled.Read more on https://www.apsense.com/article/all-about-how-to-hold-conventional-and-nonconventional-scrum-meetings.html
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Friday 28 March 2014
Means Of Communications For Collocated And Distributed Teams While Implementing Scrum
The scrum development
team
The scrum team is the heart of any scrum based project. The
development team is directly responsible for manufacturing the functionality
linked with the particular project. The development activity is carried out by
the team members during the iteration or the sprinting activity, which
generally lasts for up to two weeks. It is very important for the team members
to “jell” with each other, and collaborate, because it is a prerequisite while
implementing scrum. The physical location of the team members plays a very
important part while the sprint is carried out. In most cases, the entire
development activity, and the sprint too, is carried out in a single location,
or the same place – under the same roof. However, with the advent of off-shoring
and using scrum for complex and extended product development, it may become
necessary for the team members to remain located in different geographical locations
owing to various reasons.
Advantages of having a
collocated team
For healthy scrum implementation, high level, and frequent
communications are essential between the team members as well as the scrum master while the project is
underway. It is generally preferred that the team members are collocated.
Collocation means all the team members share a common development location, and
even similar infrastructure, during the sprint. There are several advantages of
being collocated:
· Questions can get answered
quickly and easily
· Problems can be fixed “on
the spot” with minimal wastage of time
· Less friction is created
in the interactions of the team members
· Trust is availed and
rendered much quickly
Means of communications
for collocated and distributed teams participating in the sprint
It is important to communicate in an effective manner to improve
collaboration. Several types of tools and methods can be used to improve the
collaboration among team members.
· Collocated teams
Teams working in and sharing the same office.
Since the team members
are located in the same premises the preferred methods of communications can
be:
o
Face-to-face
o
Messaging utilities
o
Internal chat tools
Discussions can also be
facilitated using:
o
Meeting rooms
o
Scrum boards
o
Wall displays
o
Shared tables
· Distributed teams
Teams placed in different geographic locations.
Some of the tools
recommended for communication purposes are:
o
Video conferencing tools and hardware/software
o
Instant messaging utilities
o
Chatting utilities
o
Social media tools
o
Shared screens
o
Remote access facilities
o
Specialized scrum software which emulate the functionality offered by
traditional scrum boards
"Please visit http://www.quickscrum.com to download the Quickscrum tool"
Thursday 27 March 2014
Types Of Burn Down Charts In Scrum – What And Why They Are Used For
In
scrum, a burn down chart is used to
provide a graphical representation of the total work remaining, or left to do, versus
time. The pending or outstanding work is generally represented along the vertical
X-axis, while the time is plotted against the horizontal Y-axis. A “burn down”
chart should ideally be understood as a “run down” chart i.e. how much of total
work is still pending and needs to be completed. Even though burn down charts
are synonymous with Agile framework and scrum methodologies, they can also be
used in other non-Agile frameworks. Basically, burn down charts can be used in
any project in which the progress can be measured with respect to time.
Scrum
supports several types of burn down charts, and they can be effectively used to
measure the progress right from the macro level. At the project level, burn
down charts can be effectively used to estimate and depict the progress made. When
the project is segregated into its fundamental components at the product level,
and when small sets of requirements in the form of user stories taken up for
development at the sprint level, the progress can still be measured using burn
down charts – even at the micro level.
Product Burn down Chart
The
product backlog, created by the product owner at the onset of the scrum
project, forms the backbone of all product related requirements in the project.
It is the main list which constitutes the product. As the product items, or the
user stories, are taken up for development during the sprint, certain stories in
the product backlog get marked as “Done” as the sprints keep on progressing. At
the end of each sprint, the items successfully developed by the team are accepted
as complete by the product owner and flagged accordingly in the product
backlog. Therefore, at any given instance of time, the product backlog can
consist of complete or pending items. The chart explaining the pending product
items and those that have been completed over time is known as the product burn down chart.
Sprint Burn down Chart
During
the first half of the sprint planning meeting, the product owner transfers some of the unfinished user stories from the product backlog
into the sprint backlog. The stories contained within the sprint backlog are
taken up for development by the team members during the daily sprint activity.
Each day, as per plan, certain user stories are taken up for development by the
programmers, and efforts are made to complete them by the end of the working
day, or the “sprint” day. As the sprint proceeds each day, certain stories are
completed, while the pending ones start reducing in numbers. The chart, which
represents how many user stories have been completed, and ideally how many
stories should or ought to be finished each day, while the sprint is underway
is known as the sprint burn down chart.Read more on http://blog.quickscrum.com/post/2014/03/06/Types-Of-Burn-Down-Charts-In-Scrum-%E2%80%93-What-And-Why-They-Are-Used-For.aspx
Wednesday 26 March 2014
Advantages Offered By Scrum Methodology – Scrum Benefits Explained For Scrum Beginners
The scrum methodology
The
usage of the word “Scrum” is inspired by a Rugby game technique where
individual team members form a group, and collaborate to fulfill a common
objective – sprinting with the ball in hand, and covering a certain distance to
“achieve” a touchdown. The concept used in scrum methodology is quite similar to the “scrum” used in Rugby. Just as Rugby
players huddle together and make efforts to gain the possession of the ball so
they can undertake the sprint to achieve a touchdown, in scrum, the individual
team members too work in unison, and collaborate to develop a shippable product
in short bursts of developmental activity known as “sprints”. Sprints are
typically short and target oriented in nature, just as they are in Rugby.
Generally, a scrum development team may consist of six to seven members working
together under a common roof, or in certain cases, they may be located in
different geographic locations.
Initially,
the main purpose of the scrum framework was
to develop and manage software-based projects. However, over the years the
pioneers who originally designed the framework put in efforts so the
methodology could evolve to suit non-IT or software based projects. However,
implementing scrum for non-IT based projects, and the fulfillment of project
goals requires specialized training, the same case as in software-based
projects. It is very important to understand that scrum is a concept – a methodology
– and it needs to be enforced or implemented in a well-planned and organized
manner for it to be effective.
The
scrum team is headed by a product owner
who represents the stakeholders and their interests while executing the
project, and is accompanied by a scrum master who oversees that scrum is properly implanted at all times while the
project is underway. The scrum development team carries out the project
development in short bursts of iterations known as “sprints”. The development
team is typically composed of trained professionals, who have specialized in a
variety of IT disciplines. They can be software developers or programmers,
software engineers, Q/A specialists, and individuals who have specialized in
other branches belonging to the IT segment.
Advantages of scrum
Scrum framework
offers many advantages not found in traditional waterfall development
methodologies:
· Responding
to the market changes
Perhaps
one of the major factors which often affect, and which may also result into an
abnormal termination of an ongoing project is the changes occurring in the
market while the project development is underway. Quite often, a project may
start successfully and proceed as per plan, but a subsequent release of more
effective and functional product may render the current object obsolete and
useless. This has happened many a times in the IT market, and many IT companies
have suffered heavy losses, and even closed down prematurely. With scrum, it
becomes easy to incorporate the changes occurring in the market. New changes
can be easily introduced in the project life cycle, and existing development
can be modified or “upgraded” to become more effectual and meaningful. In all,
scrum helps to incorporate the changes occurring in the market related conditions
as and when they occur in an easy and effective manner.
· Increasing
the ROI
Generally, when development is undertaken to
manufacture a particular product, it is usually found that approximately 60% of
the features associated with the product are rarely, or never really used.
However, their development is still carried out simply because they “are there”
and were planned to be developed when the project was intercepted. A lot of time, efforts, and cost are involved in developing the features and functionality linked with a product. If the functionality is not really useful, the efforts
and cost involved in developing the feature is wasted since it may not have a
business value attached to it. Scrum makes it possible to identify such
features, and curtail their development, which makes it very convenient for the
management to save money and human resources. In scrum, the business value
associated with the features is easily identifiable, and their development can
be regulated in a much better way as compared to other development
methodologies. The investment returns are substantially increased if scrum is
used.
· Continuously
improvising upon the project development process
Scrum supports continuous improvement in each project
related aspect while the development activity is carried out. The framework is
specially designed to identify problematic issues and resolve them as and when
they occur. A built in “mechanism” constantly helps to monitor what is
currently going on, and which of the issues are holding the organization back
in delivering the desired outputs. This is an inherent feature of scrum.Read more on http://blog.quickscrum.com/post/2014/03/18/Advantages-Offered-By-Scrum-Methodology-%E2%80%93-Scrum-Benefits-Explained-For-Scrum-Beginners.aspx
Tuesday 25 March 2014
The Main Reasons Why Work Is Not “Done” In Scrum, And Why the Acceptance Criteria Is Not Met
Perhaps the most important aspect
of scrum methodology is the concept
of “Done” or meeting the acceptance criteria while developing the tasks. The product owner, who represents the
interests of the stakeholders, approves and certifies the acceptance criteria
defined in individual user stories, or the product backlog items. It is very
much important for the user stories to be accepted as “Done” because in scrum
an item can only be considered as “shippable” and “complete” when its “Done”
criteria is met. The terminology used to describe “Done” is synonymous with the
acceptance criteria in scrum methodology. The words describe the same thing.
There are times when the
acceptance criterion is not met, and the user stories are not considered as
complete. This can be the worst possible scenario as far as conducting the
daily sprint is concerned, since the basic objective of the sprint cycle is to
meet the acceptance criteria and deliver a shippable product at the end of the
iteration. Unaccepted and unfinished user stories reflect unsuccessful sprints
and improper implementation of scrum.
It is worth knowing about some
scenarios, which can result in a condition when the “Done” criterion is not
fulfilled in scrum.
1.
Lack
of a good cross -functional team
By “cross functional” we mean a
team, or a group of individuals having different areas of specializations, who
work in unison to achieve a common objective or a cause. In scrum, if the
product is technically complex, or if the functionality associated with the
product is varied and extensive, it is essential to have a cross functional
team. When individuals with different areas of specializations work together to
develop a solution, it becomes very easy to carry out the development activity,
since the technical requirements are catered to by developers who have required
levels of expertise and can provide clear and concise solutions for a given
task or a problem. Queries are resolved in a more successful manner, and in the
least amount of time.
During the sprint, when or if a team
member faces a particular problem, it is possible for other cross-functional team
members to contribute their knowledge and skills, and provide a proper solution
for the problem in hand. This makes the development work easy, fast, precise,
and effective. It is very important, and recommended, for scrum teams to be cross-functional.
Non cross-functional team members
may find it exceedingly difficult to find quick solutions when problems arise
during the sprint activity. The primary reason why this happens is because they
lack the required experience, or do not possess sufficient skill sets to offer
effective solutions, which can solve the problem currently impeding further
product development. The levels of expertise typically required may include
designing, business analysis, development, database designing, testing, and
other similar skills. It is essential for the developer to be proficient and
very good in his or her work. Failing to have such technically sound team
members in the sprint may result in substandard or defective developmental
activity. Tasks which are not technically perfect, or which have bugs in them
may not be accepted as “Done”.
2.
Unclear
or undefined acceptance criteria in the user stories and tasks
It becomes very hard and almost
impossible for the development team to successfully complete the tasks included
in the sprint backlog if the meaning
of “Done” is not properly explained in the user story, of if the story simply fails to include the acceptance criteria
required for its development. Typically, in such cases the team starts working
blindly, and often pursues a vision of what the actual “Done” should ideally
include in the user story. Rather than the product owner explaining the meaning
of “Done”, the team assumes what the “Done” criteria is and starts developing
the task based upon their assumptions.
This can prove to be a dangerous
habit as far as the project is concerned since the entire team starts pursuing
unclear and even undefined objectives which have no relevance whatsoever as far
as the project is concerned. The result is a lot of “wastage” suffered by the
stakeholders and the management in terms of unproductive working hours and
human resources.
3.
Using
outdated or obsolete technologies for development purposes
Technology keeps on changing
continuously. For the team members, it is essential that they remain in touch
with the latest development techniques and trends. As it quite the norm,
existing technology tends to “phase out” over time, and is replaced by emergent
technologies, which are more powerful, dynamic, and effective.
Using older technologies may lead
to incomplete development, simply because phased out technologies do not have
the potential to offer the functionality needed to develop a competitive
product. Moreover, the team may find it very hard, or impossible, to meet the
acceptance criteria, and not be able to develop the task. At times, the
definition of “Done” may not be satisfied by using out dated technologies. Using
old engineering practices can lead to undue wastage of development time, and
even lead to the development of sub standard products. It is very important to
use upcoming and newly emerging technologies to deliver quality products.
4.
An
overworked development team
The stakeholders and the
management are mainly concerned with marketing the product once its development
is completed. Their objective is to launch the product as soon as possible, and
benefit from the amount they have invested in the project. They often compel
the scrum team to take up more work, or even complete the project well before
the decided completion date.
This can make the development team
to cut corners while completing their sprint tasks. Since the team is forced to
work against time, it is going to affect the development and quality of the
finished tasks. As enough time is not available to check and verify the
acceptance criteria, the team may simply decide to carry out the development
and submit their tasks in the sprint review meeting without verifying the
acceptance or “Done” criteria. The team fails to perform properly because it is
compelled to “deliver more” and it simply lacks the time to check the
acceptance criterion.
5.
Lack
of collaboration and integration activity
The main essence of scrum is collaboration.
Team members should work in a joint manner to achieve common objectives. Scrum
methodology also advocates team members to co-operate and help each other when
problems arise and solutions are required. Moreover, collaboration is essential
when the team is undertaking the sprint. Collaborated efforts lead to a
well-organized team and improved productivity.
When the team members start
working individually and stop collaborating, it leads to a situation where in the
tasks are not properly linked up, or integrated in a proper manner, to be
effective. Generally, during the sprint, the segregated user stories are
developed in the form of tasks, and the tasks have to later integrated to
fulfill the acceptance criteria. If the team members are working individually,
the tasks cannot be integrated or linked up as specified in the acceptance criteria.
The definition of “Done” is therefore not fulfilled.
Subscribe to:
Posts (Atom)