Is there is anything called sprint completion/closure criteria

[Albert Arul Prakash Rajendran]

Hi Guys,

When i was having CSM training i came to know about the definition of
Done in a sprint. I implemented the same in my organization for our
project. But QA came up with a new idea called sprint
completion/closure criteria. What does this mean

A sprint closure/ completion criteria is nothing but the QA can give
a Go Ahead for the completion of sprint if a sprint contains bugs no
more than

1) 0 Blocking bugs pending,
2) 5 High/imediate bugs pending
3) 10 Major Bugs pending.

if the number of bugs exceeds this limit, then QA says the sprint is
not complete or closed.

To my understanding the sprint will be closed on the 30th day of the
calendar month irrespective of whether we have completed all commited
task or not. If we achieve all our commitments then we call as Sprint
meeting expectation of product owner, otherwise it is not meeting the
expectation of product owner. If the pending jobs are critical, it
will be re prioritized and can have a separate sprint (of small size)
and complete those pending items.

I would like to have your thoughts regarding the same.

--
with luv,
Albert Arul Prakash
http://www.bepenfriends.com/ a free online dating web site
There are only 3 colors, 10 digits, 26 letters, 7 notes and 118
elements; its what we do with them that's important.

[Mark Levison]

How very interesting - is there any chance that your QA dept has had Agile training? Will get some soon?

When i was having CSM training i  came to know about the definition of
Done in a sprint. I implemented the same in my organization for our
project.

This is a good thing
 

But QA came up with a new idea called sprint
completion/closure criteria. What does this mean

A sprint closure/ completion criteria is nothing but the QA can give
a Go Ahead for the completion of sprint if a sprint contains bugs no
more than

1) 0 Blocking bugs pending,
2) 5 High/imediate bugs pending
3) 10 Major Bugs pending.

if the number of bugs exceeds this limit, then QA says the sprint is
not complete or closed.

This is not Scrum, Agile or even a sound practice. 

To my understanding the sprint will be closed on the 30th day of the
calendar month irrespective of whether we have completed all commited
task or not. If we achieve all our commitments then we call as Sprint
meeting expectation of product owner, otherwise it is not meeting the
expectation of product owner. If the pending jobs are critical, it
will be re prioritized and can have a separate sprint (of small size)
and complete those pending items.

Your understanding is accurate. A few thoughts:

- 30 day sprints - that's fairly long these days most coaches/trainers suggest 2 weeks. I sometimes use 1 week to get teams into the feel Scrum/Agile. 30 days has a fair chance of producing Scrumfall or Waterations (i.e. Waterfall practiced inside Agile).

- Why would accept any bugs in your stories let alone the number mentioned above. Are you automating your acceptance tests?

- Is QA part of your team? Helping to automate your acceptance tests?

- To limit bugs focus on getting stories "Done, Done, Done" rather than risking finishing a sprint with incomplete work.

Cheers

Mark Levison

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

 

I would like to have your thoughts regarding the same.

--
with luv,
Albert Arul Prakash
http://www.bepenfriends.com/ a free online dating web site
There are only 3 colors, 10 digits, 26 letters, 7 notes and 118
elements; its what we do with them that's important.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[George Dinwiddie]

Albert,

It's a shame your QA department isn't yet on-board with Scrum. Perhaps
they were left out of the training?

The sprint is a timebox. It ends when it ends. The goal is to have
*zero bugs* at that point. Meeting that goal requires working to
prevent defects rather than to find them. It can be done and it doesn't
even take expert programmers to do so.

Bugs that escape the sprint should be turned into new product backlog
items. The Product Owner gets to prioritize them along with all other
work. Whether they prevent a release or not is a business decision.
QA's job is to provide the PO with the necessary data.

I highly recommend that all sprints be the same length. A lot of stuff
becomes unnecessarily complicated otherwise. I also recommend a sprint
shorter than 30 days. Most orgs seem to start with 2 weeks these days.
It may not seem like it, but the shorter sprint really does make
things easier.

- George

Albert Arul Prakash Rajendran wrote:
> Hi Guys,
>
> When i was having CSM training i came to know about the definition of
> Done in a sprint. I implemented the same in my organization for our
> project. But QA came up with a new idea called sprint
> completion/closure criteria. What does this mean
>
> A sprint closure/ completion criteria is nothing but the QA can give
> a Go Ahead for the completion of sprint if a sprint contains bugs no
> more than
>
> 1) 0 Blocking bugs pending,
> 2) 5 High/imediate bugs pending
> 3) 10 Major Bugs pending.
>
> if the number of bugs exceeds this limit, then QA says the sprint is
> not complete or closed.
>
> To my understanding the sprint will be closed on the 30th day of the
> calendar month irrespective of whether we have completed all commited
> task or not. If we achieve all our commitments then we call as Sprint
> meeting expectation of product owner, otherwise it is not meeting the
> expectation of product owner. If the pending jobs are critical, it
> will be re prioritized and can have a separate sprint (of small size)
> and complete those pending items.
>
> I would like to have your thoughts regarding the same.
>

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Albert Arul Prakash Rajendran]

@Mark,

There is no automated testing. QA does manually. We developers has
some fair amount of use cases for every story. and we complete them
before we say the task complete. Then a build will be released by week
end ( no daily builds at this time but management is moving forward
towards the same). QA will test it for a week and will report the
bugs they find, we work within the sprint (has a separate tasks for
the bugs).

Regarding the duration, we tried 2 week sprint in our last project
which didn't worked. It was like 75% not done (some one will give time
and estimate for us). we spoke to management to make it a month so
that the team can feel little comfortable when we migrate from
process(waterfall) to another (agile). To add to this, QA Fols were
not part of two weeks sprint in that project

QA folks had training from us and another Agile coach (webinar).

Even during sprint meetings QA will not raise any question but during
retrospective they raise all issues like they don't understand
technical decisions made and lot others.

> --
> You received this message because you are subscribed to the Google Groups
> "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to
> scrumallianc...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scrumalliance?hl=en.
>
>

--