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.
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.
Subscribe to:
Posts (Atom)