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 6 August 2014
Thursday 24 July 2014
Is Agile Scrum suitable For Software Development?
The scope of
development in the software/IT field
People and individuals associated with software development and the
IT field like to use the term “software development” to describe their
particular field of work and professional involvement. The term “development”
is very widely used to describe a host of activities catering to the IT field.
It can range from developing code for applications and systems, to developing
mobile applications for mobile operating systems such as Android, iOS, Symbian,
Windows OS, etc. (visit http://en.wikipedia.org/wiki/Mobile_operating_system), “manufacturing”
gaming software using scripting languages like Ruby, AGSScript, Lua, Marathon
markup language, Ada, C++, C#, D, Lisp, Mercury, Pascal, Perl, Python, Scheme,
JavaScript, Java, VBscript, EDL, etc., (visit http://en.wikipedia.org/wiki/List_of_programming_languages) carrying out web
development using HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc., and even
developing entire operating systems for tablets and PCs (visit http://en.wikipedia.org/wiki/List_of_operating_systems, to know more about
operating systems). The fact is as on today, the terminology “software
development” is extensively used to mention almost any type or activity
associated with the programming and development of “computerizable” code of any
type, in any way, or manner. When a particular methodology or framework is used
to develop computerizable code and create software projects, it is important to
ascertain whether the scope of development includes the specific activity you’re
currently involved or associated with. Software development and projectmanagement frameworks such as Agile have the potential to develop successful IT
related projects involving the vast majority of development platforms and
operating systems.
While explaining Agile in a simple and straightforward manner, it
can be best understood as a collection of project development methodologies and
frameworks, of which any framework or methodology can be used in a successful
manner to dynamically develop projects of almost any type and nature, including
software development projects. The framework is based upon iterative and
incremental development, in which self-organised and self-managing development
teams understand, plan, and develop projects under the supervision of a project
leader, and offer productivity in the form of short bursts of development
cycles (iterative development) known as sprints. A unique feature of all Agile
frameworks is that the development carried out by the team is “shippable” in
nature i.e. the code developed during the product development cycle is
independent, testable, verifiable,
documentable, and ready for deployment after it is stringently checked
for any “manufacturing” defects.
A second, highly important feature of Agile development is that
individuals “owning” the project are closely linked with the approval of
development carried out by the team. A particular “code” or “piece” of functionality
is checked for regression after it is developed, and subsequently presented to
the stakeholders and project owners. They ascertain the development carried
out, and clear it as “OK” for future integration into the actual product. This
leads to a successful development of software projects, since the management is
always aware about what functionality is currently being developed by the team,
and up to what extent it satisfies the project objectives. If the project
owners feel the productivity offered by the team is not up-to-the-mark, or
fails to satisfies them in terms of business value (how much important the code
or functionality is from the market point of view, and how much it is worth
from the financial point of view) offered by the functionality, they can reject
the entire functionality and instruct the project manager to redevelop the
particular script or code, based upon a new set of inputs and requirements recommended
by them. This ensures that the software project always “maintains” its business
value at all times, even while the product is being currently developed.
A third important feature of Agile framework is that all activities
in the project are “time boxed”, and therefore, have to be completed within a
predetermined time period. In an Agile project, each activity is time bound.
All development related activities are “configured” to suit the unique project
needs, and a duration “affixed” to them so they can be completed within a
stipulated time. This ensures that the project does not “drag-on” and extend
indefinitely. The development costs incurred while the project is being
developed can be properly and “profitably” controlled, so that the project does
not become “too” expensive and difficult to afford financially.
Agile framework differs drastically when compared to traditional
linear or Waterfall methodology. In Agile, project development is carried out
in short bursts of activities rather than in stages that have to be “completed”
one after the other.
The main Agile features include:
· Cross-functional
development teams consisting of developers, programmers, testers, QA personnel,
technical writers, system analysts, etc. all work together as a single
composite team through collaborative efforts, offer and share ideas, and help
each other during the development process.
· Working in short,
fast-paced development cycles, with focused objectives – Iterative development.
· Shippable productivity
at the end of iterative development cycles – Incremental development. The
functionality keeps on “growing” through development cycles until the entire
application, system, or product is developed.
· Human communications
and involvement takes precedence over management authority and delegation of
work.
· Total transparency and
visibility of the team progress to project owners, stakeholders, and end users.
· Feedback and
suggestions help to self-correct and offer new ways and means to carry out
quicker, more efficient, and reliable development.
An important feature of
all Agile frameworks is that the frameworks are independent of the nature of
project to be developed i.e. the framework is not dependent upon the platform
or environment used to develop the particular software project. The architecture
or design can vary, and could be anything. The important aspect is that an Agile
framework has to be implemented in the project first, and its benefits availed
subsequently. Please visit http://en.wikipedia.org/wiki/Agile_software_development.
Scrum, briefly, is a
“light weight” Agile framework, used extensively for developing and delivering
“workable” software products, very often, and on a consistent basis. The
software products can range from the development of new web processes and
systems, gaming solutions, plugins, mobile apps, ecommerce websites, corporate
portals, development of WordPress themes, RAD (Rapid Application Development)
projects, OOPs (Object Oriented Programming) projects, CAD/CAM drafting
solutions, port programming and configuration utilities, web development and
platform interfacing solutions, etc. Scrum adheres to all Agile principles and
features discussed above since the framework is “inherited” from Agile itself.
Scrum offers a new,
and a better way of managing software projects. There are many technical
reasons why Scrum is popular and why many Fortune 500 companies prefer to use
the framework for their project development purposes. While being introduced to
Agile Scrum, a question that inadvertently comes to one’s mind is why is Scrum
so popular? Why is there so much “hype” about Scrum? Does Scrum offer a magic formula,
which can work wonders for your project and software development? Why should an
organisation that has been following a particular development methodology, and
feels comfortable doing so, should change over to Scrum? There is a separate
article which deals entirely with why you should opt for Scrum. The point is,
this article focus upon explaining Scrum to individuals who are new to the
topic, and have absolutely no idea what the framework is all about, and what it
can “do” for you. Efforts have been made to explain that Agile Scrum is
applicable to almost any kind of software development, and possesses certain features
which make the framework very popular as well as “powerful”.
The actual Scrum
process can prove to be difficult to understand, at first, for Scrum beginners.
Even though Scrum implementation is not difficult, people need to understand
and familiarize themselves about what is product increment, and how it actually
occurs during the Scrum process. The second aspect is getting to know about
Scrum events. The special meetings, known as “events” are important for
monitoring the development activity, and analysing the reliability and
effectiveness of the functionality developed by the team. They also help to
solicit feedback from the team members as well as the project owners so that
the business value of the project is not affected, and maintained at all times
– even while the product is being developed. It is worthwhile to get an
“overview” of the process first.
1.
Project conception - An idea!
All
projects, whether involving software development, or otherwise, start with an
“idea”. Projects are developed out of needs. A project is planned to fulfil a
particular requirement or achieve a certain objective. Moreover, each project
results into “something” within a specific time frame – a project cannot extend
indefinitely. It is important here to differentiate between a “project” and a
“program”. Programs are generally long termed, and can even last for years,
unlike projects which have a relatively short life span and last for a brief
period, ranging from a couple of months to even a year.
Typically,
a person, or a group of individuals realise it is worthwhile to put in efforts
and resources, and develop “something” so that “another thing” can be easily
fulfilled or availed. The “something” is the product, and the “another thing”
is the solution that the project is supposed to provide. This stage of project
development involves a lot of discussion and brain storming sessions, where the
product is envisioned and “though over”.
Scrum
does not figure during this stage. However, the vision seen by the project
owners, can, or may, affect the manner in which Scrum is implemented in theproject, in the future. This is because the nature of product to be developed
may require Scrum to be configured in a certain manner to obtain positive
results from the project.
2.
Project release – Getting started with the software
project
Once the
project is “thought about” the next logical step is to work out the
nitty-gritty concerning the project dynamics – the objective of the project,
the product definition, how the project should ideally deliver the product, in
what manner, what should be the “strength” of the team, how many team members,
etc.
Scrum development
process does not come into the picture even during this stage. The
documentation pertaining to the project is created and “everything” concerning
the product to be developed is finalised – in black and white. Scrum does not
advocate extensive documentation. You do not have to prepare detailed system
flow diagrams and extensive design structures to get started with Scrum
development. A basic idea will suffice, and you should only spend that much
time and efforts which can get you “started” with the actual development
activity. Just enough information and specifications to develop some of the
most important product features.
The
project release is attended by the “Product Owner” – the person who functions
as a project manager in the Scrum project, the Scrum Master who overseas that
Scrum is properly implemented and followed by the team while the project is
being developed, and the stakeholders or project owners who actually sponsor
the project.
3.
Creating the product backlog (Product Features List) –
Defining the product features and functionality
The Scrum development process starts with the creation of a master list containing all
features and functionality required to create the product in totality. In
simple terms, the entire product, currently existing on paper as “imagined” by
the stakeholders and project owners, is “broken down” into its constituent
parts, consisting of individual features and functionality. The product is
thoughtfully, and systematically, broken down such that each individual
component can be individually developed, tested, and eventually integrated with
other software components or functionality developed by the team over the days.
Individually developed features and functionality can eventually “give birth”
to a working product when integrated or assembled later on.
Each
individual feature or list item is known as a “Product Backlog Item” or a “user
story” in simple language. Therefore, the product backlog or the master list is
fundamentally composed of product backlog items or user stories. The user story
represents a product feature, and is individually developed by the team members
during the development process – the daily sprints. Each story can be minutely
defined. The description, acceptance criteria (Points which need to be
“fulfilled” or satisfied before which the story can be considered as
successfully developed), its importance in the project, and the manner in which
it is supposed to be integrated into the final product, etc. are mentioned for
each user story.
Once the
feature list is created, it is arranged depending upon the importance of each
user story in the product backlog. Important user stories are arranged in the
“top” portion of the list, lesser important stories in the middle, and the
least important features and functionality in the bottom portion.
4.
Sprint planning meeting – Planning how to develop the
product features
The
product backlog functions as the main “backbone” of all development related activities
in Scrum. Once it is “developed” by the product owner and the stakeholders, the
actual development activity can start. A special meeting known as a “Sprint
Planning” meeting is held to initiate the development activity. The meeting is
attended by the entire development team, in addition to the product owner “PO”
and the scrum master “SM”.
The
meeting is held in two parts. In the first part, the product owner selects some
of the most important user stories or product features from the top of the
product backlog, and transfers them to a temporary list known as a “Sprint
Backlog” for development purpose. During the meeting, the product owner takes
the opportunity to explain each user story in details to the team members – how
user stories should be ideally developed, and what activities the team should
carry out so that each story can be marked as successfully completed.
During
the second half of the meeting, the development team analyses the sprint
backlog and distributes each story to individual team members. In practise, the
team members unanimously decide as to who should take up which story depending
upon their development skills and experience levels. Simple and easily
developable items are given to less experienced or “fresher” while difficult,
or more complex stories are taken up for development by more experienced and
senior programmers or developers.
This is
the main area of activity in Scrum. The entire product is developed in “bits”
and “pieces” through the daily sprint cycles. A sprint cycle is nothing but a
collection of working or “development” days during which the team members
actually sit in front of a PC and develop the functionality or product features.
The sprint cycle is time boxed and should not extend its deadline.
Each item
included in the sprint backlog during the sprint planning meeting should be
developed while the sprint is currently underway. A brief meeting known as a
“Daily Scrum Meeting” is held for a maximum of 15 minutes each day before the
team members start with their work. The purpose of the meeting is to get an
idea regarding how much work has been completed by each member the day before,
and what each member proposes to do “today”. If a team member is facing any
issues or problems, it can be mentioned during the meeting, and the scrum
master will ensure that the issue is quickly resolved.
In Scrum,
the daily sprints can typically last from 2 weeks up to a maximum of one month.
The duration of the sprint is decided during the second stage - the project
release - and it should not be extended under any circumstances - even if any
of the user stories in the sprint backlog have not been developed, or whose
development is incomplete.
6.
Sprint review – Checking and verifying productivity
(Is the development OK?)
Scrum
emphasises upon the development of “shippable” functionality at the end of
daily sprint cycle. Each user story developed during the daily sprint is
checked by the product owner and verified for its reliability, acceptance
levels, and whether it is “bug free”. In Scrum, it is very important to deliver
error free features – each user story should be properly tested for any
regression, and whether it satisfies the acceptance criteria linked with its
development.
Just
after the daily sprint cycle ends, a meeting is immediately held to review the
development carried out by the team. It is important to differentiate between
the daily sprints and the sprint cycle. The daily sprint is the development
activity carried out by the entire team on one particular working day. Many
such “daily sprints” combine to form the “Daily Sprint Cycle”, also known as
the “product incremental cycle” in Agile. The meeting is held at the end of the
product incremental cycle – the daily sprint cycle. It is primarily attended by
the product owner, the scrum master, and the team members. It is not mandatory
for the stakeholders to attend this meeting. They can chose to attend it if
they so desire.
The main
objective of this event, or rather the meeting, is to check whether the
features have been developed by the team as per the production plan, and if the
functionality has any “manufacturing” defects. Each feature should be fully
tested for any flaws by the team before presenting it in this meeting. The product
owner verifies if the feature is error free and checks if it satisfies the
acceptance criteria linked with it. It is a kind of “final” check carried out
before presenting the development to the stakeholders and the project owners in
the subsequent sprint retrospective meeting. During the meeting, the product owner
instructs the team how it can improve its working and offer even better
productivity by employing more efficient programming practices and standards.
7.
Sprint retrospective – Finalising product
functionality and contemplating about further improvement
Agile Scrum advocates client participation. The client
is a very important entity in Scrum, and has the final say as far as the
development of product features is concerned. The Agile manifesto primarily
stresses upon client participation and delivery of time bound product
increments because these two aspects are very important for developing
successful projects. A “satisfied” client often “comes back” to develop more
projects since successful projects help the client to earn higher profit
margins.
The retrospective provides an opportunity for the
entire team to demonstrate its productivity in front of the stakeholders and
clients. In addition to the product owner, scrum master, the development team,
the meeting may also be attended by end users, technical staff personnel,
vendors, distributors, and even other employees since the main purpose of the
meeting is to avail feedback from individuals and entities closely linked with
the market, and who have sound knowledge regarding what product features are
likely to “score” in the market once the product is launched, and what can aid
the product in “selling”.
The retrospective also offers a chance for the entire
team as well as the client to reflect upon the development process, and discover
what more could be done to make the product better. Discussions are carried out
to ascertain the rate at which user stories are currently being developed by
the team, and what new processes or methods need to be introduced to quicken
the process.
Monday 21 July 2014
What Should The Perfect And Ideal Daily Stand-Up Scrum Meeting Consist Of As Per The Official Scrum Guide?
The
daily stand-up scrum
meetings play a vital
role in ascertaining that the development activity is carried out in a
sustained manner. The meetings are usually time boxed to 5–15 minutes and are
held standing up to remind people to keep the meeting short and to-the-point.
Stand-up scrum meetings also help to find potential pitfalls experienced during
ongoing sprints. It is important to know how the daily meetings are carried
out, and what they should ideally consist of. On the basis of official scrum
guide specified by Jeff Sutherland and Ken Schwaber, the originators of scrum methodology, the article
tries to explain in details about the daily scrum meetings.
· Who should attend
the meeting?
Everyone
associated with the scrum project should attend the meeting. It is
important for the scrum master and the team members to remain present, while
the product owner and stakeholders too can remain present if they desire to do
so.
· What should be
discussed during the meeting?
It is
very important to remain focused and only discus about those topics which are
directly related and associated with the sprint activity. The attendees should
try not to wander off the main topic and discus about other trivia which are
not pertaining to the scrum activity. In fact, the guide is specific about
discussing topics which are directly connected to the sprint to be carried out
during the particular day, even other topics dealing with the project, or
project related issues should be avoided during the stand-up meetings. There
are special provisions like the sprint retrospective meeting to discuss about
such issues.The main topics to be included during the meeting should consist of:
- What
tasks were accomplished during the sprint carried out the day before?
- Which
tasks are to be developed today?
-
Did the particular
team member face any problems or impediments during the sprint implementation?
If so, what were they?
· In what order
should the discussions be carried out?
There
is a lot of flexibility while deciding about the order in which the discussions
can be carried out during the meeting. Team members can take turns in discussing
about what they have achieved, and what they plan to do on the particular day.
Alternatively, the scrum
master may decide who
should speak first and which team member should follow the discussion. A
popular method is to take up discussions regarding important tasks first,
followed by the order of priority. The order of discussion can vary from
project to project, and from need to need.
· Where and when
should the meetings be held?
The
stand up meetings should be ideally held at the place of work, and in front of
the task board. While they can be conducted almost everywhere, including
conference rooms, holding the meetings in the actual place of work can help the
team members to remain more focused and target oriented. The meetings should be
held before the daily sprint is initiated.
· How to sustain the
energy levels during the meetings?
The
stand up meetings are also commonly referred to as “huddles” by many people,
simply because each team member stands very close to the next one during the
meeting. The scene is much similar to the scrum used in rugby. The proximity
often encourages the team members to become proactively involved in the
discussion. The energy levels start rising up as each team member briefly, and
professionally, discusses and outlines his or her activity for that particular
day. The meeting is to be held in such a manner that the “atmosphere” becomes
charged up with anticipation, and each member focuses upon the goals he or she
plans to achieve during the sprint carried out that day.
Monday 14 July 2014
What Is Sprint Planning And What Do The Sprint Planning Meetings Actually Consist Of Or Include?
The
primary objective of a sprint planningmeeting is to discuss and plan about what the development team intends to
build or develop in the upcoming sprint, and how the individual members of the
team are prepared to go about with their development activity. Though most
experts refer it to as a “single” meeting, it is in fact segregated into two
unique parts. The first part concentrates upon what the team is actually asked
to build or develop, and is attended by the team members as well as the product owner. The second part of the
meeting focuses upon how the team members will proceed with the actual
development work. The team members are to mandatorily attend both the parts of
the meeting, while the product owner is committed to attending the first part
only. He or she can however attend the second part if he or she wishes to do
so.
The first part of the sprint planning meeting
During
the initial part of the meeting, the product owner has an opportunity to
explain in depth about the set of user stories to be developed during the sprint. It is a rapid-fire type of
discussion in which the product owner initially explains the user stories, and
subsequently the team members start asking questions regarding the points they
are not clear about. The product owner has many responsibilities and roles to
play. The person represents the client’s interests, explains how the stories
are to be linked up in the future, and keep tabs during the entire development
activity carried out by the team members. The objective of the meeting is to
provide enough information, or brief the team members regarding the development
activity required so that each member can carry out his or her part without any
confusions or problems.
The
questions typically asked during this stage of the meeting are:
· What is the acceptance or “passing” criteria
of all the stories?
· What kind of data sources need to be used?
Where will the data originate from, and where will it go?
· How should the developed component look
like once it is fully developed?
The second part of the sprint planning meeting
During
the second part of the meeting, the team further analyses the user stories and
focuses upon creating the sprint backlog
which includes the user stories, or the set of requirements and functionality
to be developed by the team members during the sprint. The team typically
segregates the user stories into individual tasks, and links up, or associates each
task with a certain time scale i.e. the duration in which the particular task
is to be developed. Generally the tasks are planned to be completed on an
hourly basis, however, the time period can be more depending upon the
complexity and the levels of functionality to be incorporated into the given task.
Another main objective of this part of the meeting is to accept the user
stories as practical and “doable”, and to reject those stories which cannot be
catered to, owning to various reasons.
The
duration of the entire sprint planning meeting can range from two hours up to
eight hours depending upon the number of user stories involved, and the levels
of complexity. The rule of the thumb is to spend one hour of discussion for
each week of sprint.
Thursday 10 July 2014
What to Consider Before Writing User Stories in Scrum So They Can Be More Effective and Meaningful
User stories in scrum
A user story is the main functional unit in scrum methodology. When any project is
taken up for development using scrum, the specific requirements for that
particular project is stated by creating a set or development requirements,
which are termed as user stories in
scrum. Usually the product owner
creates the product backlog – the
list of requirements needed to develop the project. The product backlog items
are referred to as user stories by scrum professionals. Once the product
requirement list is created, a small set of the requirements (user stories) are
transferred to the sprint backlog during the sprint planning meeting for development
purposes. The stories are explained to the team members in the first half of
the sprint planning meeting. During the second half, team members distribute
the stories after breaking them down into development tasks. A sprint backlog
is prepared in this way. Subsequently, the team starts developing the
functionalities of the user stories during the daily sprint. In scrum, the
entire project is governed on the basis of the user stories.
The official scrum guide does not attempt to provide a
specific definition that can describe the “structure” of a particular user
story. The guide actually explains what a user story is, and what part it is
supposed to play in the project. It fails to provide a standard format which
can explain as to how a user story should really look like. Maybe, the reason
why the guide fails to provide a structural definition is because development requirements
can vary from one particular project to another. So, it becomes difficult to standardize a specific
format compatible to all types of projects.
The guide, however, states that the user story should ideally be composed
of three constituent parts, or include there main aspects:
1.
A
written description or a graphical representation of the entity which forms a part
of the project
2.
A detailed
conversation, or an explanation which additionally describes the functionality
in greater details
3.
The
acceptance criteria or “Done” meaning which specifies what the entity should
include, how it should function, and the particular manner how it should migrate
or integrate into the project
What should be considered while writing or
creating user stories
While
writing the user stories, certain points are important, and should be adhered
to for the user stories to be effective and developmental:
· Stakeholders
should create or write the user stories
The
investors and the stakeholders are funding the project for financial gains.
Each project has a financial value attached to it in terms of how much the
project will be worth in the market. The stakeholders know which user stories
are important, and which functionalities will increase the value of the
project. Therefore, they are the ideal individuals to define and create the
list of requirements or the user stories. The product owner carries out the
work on their behalf, and represents their interests while the project is being
implemented.
· Using
simple tools to represent user stories
In
the manual system, stories are written down on index or story cards specially
designed for scrum. The scrum index cards are very convenient to work with, and
are generally pinned on the scrum board while the sprint is underway. It is
important to use a tool that is small in size, so it can be easily stored and
pinned on the scrum board. It should be easily readable, simple to understand,
and effective. The more simple and effective the tool is, the easier it would
be for the team to understand and use it.
· Time
to be allotted to the user story
Scrum
advocates time bound activities. Each activity in scrum has a certain duration
associated with it, and is “time boxed”. It is important not to exceed the time
limit to get the most out of scrum. Each user story is allotted a certain
duration within which its development should be completed. It is essential that
each user story is completed in the time allotted to it since it has a certain
importance value (story points) attached to it. The project turns out to be
cost effective only when the right duration of time is allotted to each user
story, and each story is completed in the time allotted to it. If the time
limit is not allotted, the project becomes expensive and its ROI decreases.
· Describing
and stating important non-functional aspects
Certain
user stories need to be explained in further details so the team members can
properly understand them. The user stories may be very important in terms of
how they provide a solution for a particular end-user related requirement. They
may or may not be technically complex, but it may be important for the team
members to know what part the user stories are likely to play, and how much
important they are as far as the overall project development is concerned. Such
non-technical aspects of user stories should be explained properly so a better
overview and understanding of the project related requirements is availed.
· Fixing
the story priority
Each
user story has a certain level of importance attached to it development. It is
important to prioritize the user stories, so the correct time can be fixed for
its development. Important user stories, or those which have more importance
attached to their development, should be assigned a higher priority, and
sufficient time should be allotted for completing them. On the other hand, less
important stories ought to be assigned less time and priority because they do
not carry much financial value with regards the functionality they offer. .
Monday 23 June 2014
Does Agile Exist Once You Implement It In Your Project?
As on today, if you
search for Agile, or Agile related information over the internet, you will be
greeted with search result pages displaying all sorts of information pertaining
to Agile – right from Agile training and coaching to Agile gurus offering their
“esteemed” insights and experience relating to various Agile frameworks. More
recently, it has become very common to see scaled versions of Agile appearing
in the searches – SAFe, Scaled Agile, ScrumButs, AgileLive, Jira Agile, Quickscrum - the
list is not big but worthy of being considered – and all of them proclaiming
their efficiency in being “effective”, and above all “Agile”. It would be
wonderful to know more about these versions, but a basic question always keeps
on popping up – Is the client really following Agile in a true sense? Are you a
hard-core Agile supporter or a ScrumBut? Maybe, it would be more worthwhile to
ascertain whether you, or your client, are in fact following Agile in the first
place, let alone other scaled versions of Agile.
Here are a couple of
pointers to help you know if you are “Agile” or not.
Is development carried out through iterations?
Needless to say, the
main purpose of implementing an Agile framework is to benefit through product
increments in a consistent manner. Nobody can claim they’re following Agile if
their project development process does not support regular product increments
at the end of sprints. In addition to iterative development, Agile
implementation should also support dynamic collaboration – sharing of feedback
and information amongst the product owner, scrum master, scrum team, and the
stakeholders. Iterative development and collaborative nature are Agile trademarks,
and it is most essential for organisations to support these features if they
claim to be Agile.
Can changes be incorporated during the product
development cycle?
One of the main
reasons why people opt for Agile is its ability to incorporate changes in the
product definition even while the product development process is currently
underway. It is a unique selling feature of all Agile frameworks, and is
synonymous with developing a project while still maintaining its business value
– at all times. Irrespective of the changes taking place in the market –
whether big or small – the project development process should have, and retain,
its capability to dynamically change the functionality developed, and offered,
by the product features as and when necessary. Agile projects should support
this feature.
Can development be carried out in “bits and pieces”
rather than “as a whole”?
Perhaps what makes
Agile frameworks so unique are their iterative structures supporting daily
sprints. In scrum or XP, the product development is carried out in the form of
daily sprints. Special events are held to plan the sprint (the sprint planningmeeting) and ensure that proper and acceptable product increments are availed
at the end of sprints (sprint reviews and retrospectives). The development
carried out in “bits and pieces” should result into shippable functionality
(successfully developed user stories), and should also be acceptable to the
project owners (stakeholders). “Small sized” consistent development, which is
bug free, should have the capability to later integrate in a correct functional
manner so as to form the “complete” product – an euphemism which conveys
“Development in pieces to be later integrated to form the actual product.”
As on today,
organisations are not just limited to using traditional versions of Agile
frameworks. There are subtle variants, which can be scaled up or down as per
the need, and which can be “tailored” to meet the unique project development
needs of business concerns. It may not be possible to state or define the exact
set of parameters which a project management methodology, or framework, should
satisfy to be considered Agile, since Agile is all about “inspecting” and
“adapting”. The main essence of Agile lies in its ability to change itself, its
working, and mould itself to suit the specific development related needs, as
the case may be.
However, it may be
certainly possible to “check” for some “trademark” features to ascertain
whether Agile exists in a project or not.
Use Free scrum tool from www.quickscrum.com
Source:-
http://EzineArticles.com/8576627 |
Friday 20 June 2014
Quickscrum - Tool to Consider
This tool for managing projects
scrum type, to manage in a simple way the entire project, ie customer, product
owner, members, assignments, sprints, priorities, task description, and even
even graphs showing progress and evolution .
It's kind of collaborative,
allowing dragging of objects, as is done for example in Trello ,
app that we use and we are very pleased also.
It can be used in free mode, up
to 5 users, 3 projects but without any ability to store files, while offering
other alternatives (fee-and not so expensive) that increase performance, of
course. Right?
Say to prove it is worth it
because it really is very easy and convenient to use.
To access the official site, I
leave the link: http://www.quickscrum.com
If someone was using it, would
be nice to tell us what your opinion on this software is because it's like
everything else, as you will be entering information and interacting with the
app, you are giving certain situations to solve.
One thing I asked was if the
development team can connect to applications like: Test link, Mantis or
Redmine, and I responded that for the next release plan to incorporate a bug
tracking.
It will be a matter of
following your steps and see how this another module that also serves both us
us.
Monday 9 June 2014
A Brief Overview about What Is Agile Scrum Framework and How It Can Help You in Developing Successful Projects
Scrum is a
specialized type of project development framework. It is very popular owning to
its fast and reliable product development cycle. It can be used for developing
products, especially software based products, for which it is very extensively
used nowadays. Many Fortune 500 companies currently use the scrum development
methodology across the world owing to its popularity and effectiveness in
delivering high quality products within the stipulated development time. The
unique aspect about scrum framework is that it has an ability to “inspect” what
is happening “in” and “around” a project in which it is implemented, and it can
take corrective actions based upon the findings received as inputs from the
process flow. The framework supports several activities known as “events” which
can help to identify if anything wrong is happening with the project. When a
malfunction or an erroneous activity is detected, the framework can take
corrective steps to ensure that the “wrong” thing is corrected and rectified in
a correct manner. The scrum framework is so structured that it can
“self-detect” and “self-correct” itself through its events and specialized working.
Typically, scrum is
a development process in which teams collaborate and work together while
creating the product. In scrum, development occurs in small stages known as
“sprints.” Each small burst of development activity, or sprint, generally lasts
from two weeks up to one month. At the end of each sprint, a special event
known as the “sprint review” is held to find out how much development work has
been carried out by the team, and how much of it is acceptable from the quality
control point of view. Completed work is consolidated and accepted as “Done.”
The unique aspect about scrum is that development is carried out in bits and
pieces, rather than “as a whole” and “all together.” Each piece or
developmental unit is developed individually and tested for flaws. These pieces
are subsequently integrated to form the complete product. Rather than
controlling the project as a whole, scrum ventures to control the development
of individual pieces or product functionality. The developmental units, or “pieces”
are referred to as “user stories” in scrum. Once all the user stories are
developed and integrated, a total, comprehensive, and “shippable” product is
automatically developed. This product is tested at a micro level with regards
its functioning and reliability. This is one of the major reasons why many
development companies and organizations prefer to use scrum framework in their
production processes.
There are many
reasons why people choose scrum for their project development activity.
Reduces technical debt and eliminates regression
At any given
instance of time, the team develops a small portion, or a thin slice, of the
actual product. This portion is further divided into even smaller developable
units that are individually developed by the team members. Once a particular “unit”
is completely developed, it is tested for its completeness and usability. It
provides an opportunity for the team to test individual product components at a
micro level. Tackling problems at a root level leads to zero regression and
highly reduced technical debt in the future. This is how scrum controls
technical debt related problems before and after product deployment.
Maintain the business value of the project at all
times
After a small
portion of the product is developed and tested for its reliability, it is
demonstrated or showcased to the project owners and stakeholder – people who
actually own the project. Their feedback is availed regarding the functionality
which has been developed by the scrum team. Once they Okay the development, the
portion is accepted as “Done.” If the owners are not satisfied, the development
is transferred to a master list from which it can be taken up again for
development purposes. Thus, only useful and effective developmental activity is
carried out in the framework. The system is so structured that it can reject
substandard work. Moreover, each developmental unit can be correlated with its
“worth” in the market i.e. when a particular functionality is developed by the
team how much it will be worth in the market when integrated in the actual
product. This ensures that only meaningful development having a certain
financial significance is “churned” out by implementing the scrum framework.
Each product unit developed has a certain business value attached to it. This ascertains
that the business value of the entire project is maintained at all times.
Collaborative features which can streamline
productivity and increase it
One of the biggest
advantage of scrum framework is that it solicits feedback from the team members
and the project owners at all times. Each user story, or the development unit,
is precisely stated in a master list known as a “product backlog.” This master
list contains each and every “item,” or a developmental unit needed to develop
the product in totality. Each item in the list is minutely defined. The
specifications of the functionality to be developed, its description,
explanation, and what benchmarks it needs to satisfy to be accepted as “Done” are
clearly stated in it. This makes development much easier for the team members
since the criteria is clearly laid down and the team knows exactly what
functionality to develop, in what manner, and what kind of outputs are expected
after developing the product item. The feedback system further helps the team
to collaborate and discuss the technical aspects regarding the development
activity. This helps to streamline the production process. The team members can
help each other during the product development phase. All senior as well as junior
team members support the collaborative nature. When the team faces any problems
or impediments, a project leader known as a “product owner” tries to provide a
solution for the problem – if necessary by interacting with the stakeholders
and other technically sound individuals. The collaboration process helps the
team to function in a highly productive manner.
Adapting to changing market conditions and developing
successful projects
A major advantage
with scrum is that if follows the “inspect” and “adapt” principles. The
framework possesses inherent features which facilitates inspection and
retrospection. The development of a product can take a certain time. If the
product definition is complex or complicated, it may take a longer time – even
months – to develop the product in totality. Many a times while the product is
being developed, the market conditions may change over time and render some of
the functionality associated with the product as redundant. As a result, a
product when launched in the market after months of development may lose its
business value and find it difficult to compete with other similar products,
because other products may have gained a “stronghold” and strengthened their
position owing to their prior release. Companies more than often suffer
substantial financial losses when this happens. Scrum helps to avoid this. The
stakeholders are very closely associated with the project during its
developmental phase. They have the opportunity to decide which of the product
functionalities carry high business values, and which functionalities can help
the product to succeed financially in the market. During the product
development cycle, the stakeholders can introduce new functionality, remove
existing functionality, and even suggest changes in existing functionality so
that the entire project is able to maintain its business value at all times –
during its inception, development, and the subsequent release. Projects
developed using scrum framework are profitable and help to earn higher ROI for
the stakeholders.
These are only a couple of reasons why organisations
across the world opt for scrum framework. The are many other factors which
entice “C” level executives and mega corporate to choose scrum as their
development framework, however, it would take a much more detailed discussion
and a personal coaching to truly understand the vastness and depth offered by
scrum. The framework is so agile that it can adapt to almost every type of
project, however large and complicated it may be, and still deliver it
successfully and nicely “wrapped up” for its final deployment. It is worth
knowing something more about scrum to avail a better picture about how it
functions.
The scrum process starts
with an activity known as a “Release Planning.” When a project is planned, or
decided, the stakeholders appoint a person to execute and look after the entire
project. The person is known as a “Product Owner.” The person represents the
stakeholders and their interest in the project. The product owner (or the “PO”
in short) starts planning about what needs to be done to execute the project in
a systematic and planned manner. He or she starts preparing the documentation
which includes various aspects concerning the project, such as the feasibility aspect,
market dynamics, product specifications, etc. The report is presented to the
stakeholders, which helps them to decide further as to what they actually need
and desire out of the project. The report helps the stakeholders to understand
the reality about how the product proposed by them is likely to perform in the
market based upon what they have envisioned. This process is generally known as
a “release planning.” The PO then proceeds with the project based on their
feedback and suggestions. The PO starts preparing a master list known as a “product
backlog” in scrum. The list contains individual items, known as “product
backlog items” or “user stories,” which are required to develop the entire
product. So looking at it conversely, the entire project is bifurcated into
smaller individually developable parts known as user stories, which actually form
the product backlog. The PO carefully writes down these stories. He or she can
also invite and take help from the team members while drafting the stories. The
stories include specifications about the functionality to be developed by the
team. Once the backlog is created, the PO analyses which of the stories are
most important from the functionality point of view, and which of them carry
high business values. Important stories are located in the top of the list so
they can be developed first. Generally, the product backlog is processed from
top to bottom, so important stories can be developed first.
The sprint planning meeting
The actual
development activity starts with a scrum event known as “Sprint Planning.” A
meeting is conducted to support this event. The sprint planning meeting is
actually held in two parts. During the first part of the meeting, the PO takes
some of the important user stories from the top of the product backlog and
transfers them to a temporary list known as a “Sprint Backlog.” This list is
important to the team members since it contains the product items which are to
be developed in the subsequent days. During the meeting, the PO explains what
needs to be developed, in exactly what manner, and what conditions need to be
satisfied to have the user stories accepted as successfully completed. The
conditions are known as “Acceptance Criteria.” The team avails an opportunity
to ask questions and seek clarifications regarding the subtle development
points which are not clear. In the second half of the meeting, the team
analyses the sprint backlog which contains items to be developed in the coming
days. The members split up the stories into small developable sub-units known
as “tasks.” Once the tasks are distributed amongst the team members, the actual
development process starts.
The daily scrum or “stand up” meetings
In scrum, the actual
product development is carried out in short bursts of activities known as
sprints. A sprint generally lasts for two weeks up to a maximum of one month.
The PO and the team collectively decide the actual duration of the sprint keeping
in mind various factors such as the level of complexity, size of the projects,
the product release date, etc. Once a sprint duration is decided, it is “fixed”
and cannot be changed later on. Each day, before the developers start with
their day, a brief meeting is held to initiate the daily sprint activity. This
meeting is called the “stand up” meeting or the “daily scrum.” The reason why
the word “scrum” is used to describe the meeting is that scrum team members
huddle together just as rugby players do on the field when they start with their
“rugger” scrum. The purpose of holding the meeting is to make the team
accountable for the work it has carried out the day before, and discuss what
work is to be carried out on that particular day. The daily scrum meetings
provide an opportunity for the team to briefly discuss and provide feedback
regarding how many tasks have been completed by them. If any team member faces
an issue or a problem, it is discussed in the meeting and a solution is availed
to resolve the impediment. The meeting is very brief and time boxed. It should
not extend for more than 15 minutes. The meeting is held on each day of the
sprint to “start the day.”
The sprint review meeting
The development work
is carried out by the team in the daily sprints. At the end of two weeks (sprint
duration), when the sprint is completed and user stories have been developed by
the team, the PO checks the development and verifies whether the stories have
been developed properly, and whether the acceptance criteria is satisfied
correctly. In scrum, it is very important to develop “shippable” functionality
i.e. the tasks developed by the team should be bug free, documented, tested,
and acceptable by the stakeholders. Many cross-functional scrum teams employ
testers and QC personnel whose sole task is to check whether the user stories
developed by the team fulfil the acceptance criteria. If this is not possible,
the PO evaluates the tasks and verifies whether they are acceptable. This
process is carried out in a scrum event known as the sprint review meeting. It
is held just after a sprint is completed. The main purpose of this meeting is
to verify the development work, and if some of the tasks do not fulfil the
acceptance criteria, they are “rejected” and transferred back to the product
backlog from where the user stories can be taken up again for development. Thus,
regression is “checked” and controlled through the scrum process.
The sprint retrospective meeting
The scrum process
invites feedback from the stakeholders. People who own the project get a chance
to check the productivity and provide feedback while the product is being
developed. In scrum, the development and productivity of the team is directly
and indirectly controlled by the feedback received from the stakeholders, end
users, and the technical teams. If productivity is carried out by the team in a
proper and acceptable manner, the user stories and tasks developed will have a
certain business value attached with the functionality linked with the tasks. A
scrum event known as the “sprint retrospective” provides an opportunity for the
stakeholders to ascertain the work carried out by the team. The sprint
retrospective is held immediately after the sprint review meeting. The main
difference between the review and the retrospective is that in the review the
PO verifies the tasks and checks for acceptance criteria, while in the
retrospective the stakeholders check the user stories and tasks for the
business value availed in the ongoing project. While the PO is primarily
concerned with the technical aspects and represents the stakeholders’
interests, in the retrospective the stakeholders see for themselves how
important the user stories are from the business point of view. The
retrospective also offers an opportunity to educate the team and offer valuable
suggestions to enhance the project vision and make certain aspects clear to the
development team as to what the team should ideally focus upon.
Scrum Roles
Product Owner
He or she is the
main person who executes the scrum project. The person is primarily responsible
for the success or failure of the scrum project, and, in addition, represents
the stakeholders’ interests while scrum framework is being implemented in the
project. There are many responsibilities of the product owner, and it would
take a lengthy discussion to explain all of them.
Just as a supervisor
overseas the production process in a manufacturing unit, similarly a scrum
master overseas that scrum framework is properly implemented at all times while
the project is underway. The scrum master does not actively participates in the
development work carried out by the team, but rather “keeps an eye” on how
things are going on and whether the team faces any impediments while work is
underway. The role of a scrum master is a passive one, but important. The PO
generally does not have enough time to oversee the entire project operation
since he or she is actively busy with the “macro” aspects concerning the
project. The scrum master, on the other hand, concentrates on the “micro”
aspects of the project and remains very close to the team, and helps them
directly and indirectly by removing the obstacles whenever the team faces them
in any way or manner.
Development Team
It is the main
“functional” unit of the scrum team. The product is actually developed by the
development team in scrum. Ideally, the development team is cross-functional
i.e. each team member possesses multiple and varied technical expertise. The
team members collaborate and share ideas while working.
Scrum Artefacts Or Objects
In scrum, the entire
product is broken down into smaller, individually developable units known as
user stories. User stories, also known as product backlog items or PBIs, are
developed by the team during the daily sprints depending upon their importance
and business values. They form the base of the entire product. Individual user
stories are later integrated to form the complete product. Typically, user
stories include a title description, an explanation describing the
functionality to be developed in the story, some important points that clarify
the development activity, and the acceptance criteria. User stories also
include a numeric value which indicates how important the particular story is
from the business value point of view. This value is the “story point.”
Product Backlog
It is the master
list which includes the product backlog items, or the individual product
components, which constitute the actual product developed in the scrum project.
Periodically, the product backlog is checked and verified for any missing
parameters in the user stories (whether any of the product backlog item is
inappropriately described or lacks proper acceptance criteria) and the business
value associated with the user stories. With time, the business values of the
user stories change with changing market conditions. The stakeholders provide
feedback regarding the changes in the business values of the user stories, and
the product owner updates the user stories with the new business value as
provided by the stakeholders. This process of updating the product backlog is
known as “backlog grooming” or “backlog refinement” in scrum.
Sprint Backlog
During the daily
sprint, the user stories prevailing in the entire product backlog are not taken
up for development. Rather a small “chunk” or portion of the product backlog is
taken up for development during the daily sprints. This small portion of the
product backlog is temporarily stored in a list known as the sprint backlog.
The PO creates the sprint backlog during the sprint planning meeting.
Burn down Chart
Each user story in
scrum is associated with a certain business value by using story points (a
numeric value indicating the importance and the business value of the user
story). The correlation of the user stories with story points is important in
scrum since it becomes possible to find the “rate” at which the development
team is “performing.” It becomes easy to create an estimate and determine the
“speed” at which the team is currently developing the user stories. This
estimation can be plotted in a chart, or a graph, known as a “burn down chart”
in scrum.
The QuickScrum
project management tool developed by Bharti
Softtech is a powerful, easy to use, and versatile web based scrum tool
application centred upon Scrum framework. The tool helps to incorporate scrum
methodology into project development, and offers a dynamic scrum management
environment. It includes powerful features such as easy to use drag-and-drop
features, dynamic update of each product backlog item, its status, breakdown of
backlog items into individual tasks, preview of backlog items created in
earlier sprints, and much more. It is ideally recommended for organisations, project
managers, and scrum teams desiring to implement scrum framework in their
projects. The tool helps to save time, reduce operational overheads, and
increase the development team’s productivity, which can lead to higher profits
and increased ROIs.Source:- http://blog.quickscrum.com/post/2014/06/06/A-Brief-Overview-about-What-Is-Agile-Scrum-Framework-and-How-It-Can-Help-You-in-Developing-Successful-Projects.aspx
Please visit http://www.quickscrum.com for
additional details.
Subscribe to:
Posts (Atom)