headers
john_hermann | 1 Mar 2010 01:10
Picon
Favicon

Re: Manual testing


Yes, thanx for the clarification Ron.

Acceptance Criteria should probably be part of a team's definition of "Done" - so the items "done" earlier
in the sprint should already be known to be "acceptable".  The later items will be known to be acceptable
closer to the end, but are sometimes rushed with a potential lapse in rigour that I would call
"get-there-itis" (to borrow the term from the airline industry).

So yes, the confidence level should be high already prior to any dress-rehearsal demo, which itself should
be limited to reassurance.  When you have the "whole company" showing up for a review the next morning, a
manual demo test can increase confidence for the team, especially the person actually doing the demo.  Or
perhaps its just me: I would never walk into a meeting with the CEO present to present/demo something
without having done some manual "testing".

Aside: Thank-you Ron for all you have given via XP!

-johnny

--- In scrumdevelopment <at> yahoogroups.com, Ron Jeffries <ronjeffries <at> ...> wrote:
>
> Hello, john_hermann.  On Monday, February 22, 2010, at 10:16:20
> PM, you wrote:
> 
> > One team I worked with would do a manual dress-rehearsal demo the
> > evening before the Review meeting (the following morning).  This
> > preparative "testing" gave them a confidence level for what
> > stories would likely be accepted by the PO, and indeed what
> > stories to demo at all, since you should probably not demo stuff you know is not "acceptable".
> 
> Yes ... however the team should know, long before the demo, whether
(Continue reading)

Permalink | Reply | 0 comments |
headers
john_hermann | 1 Mar 2010 02:25
Picon
Favicon

Re: Baselining and Scrum


Yes, baselining seems to be fairly non-agile, and rooted in traditional PM.  It exists mostly for logistics
(vs. development) projects, where a lot can be known up-front, and hence there is little "excuse" to
deviate from plan.  When you do deviate, management wants to see the deltas of "actuals" from
plan/"baseline", to see what went "wrong", to create indexes, to make predictions, etc.  Such deltas are
checked frequently to make sure that the output is not going off track, or out of budget, or off schedule.

In Scrum, such a delta comparison occurs when comparing velocity sprint to sprint, and making predictions
about what can be accomplished in the next sprint based on the previous one(s).  Since sprints are short,
the "check" occurs frequently enough, and since sprints are ideally "atomic" in scope, no deviations
from "baseline" should occur intra-sprint. (There are always exceptions.)  So I agree with whoever it was
who said earlier that Scrum already takes care of the needs of baselining.

Also, as has been mentioned elsewhere, a performing team will eventually stabilize into a fairly regular
velocity.  Perhaps story points can even be eliminated, thus counting only the number of stories
themselves.  If the team changes, or has not stabilized, then the "baselining" of Scrum helps keep things
organized. 

-johnny

--- In scrumdevelopment <at> yahoogroups.com, Monde Hans <monde.hans <at> ...> wrote:
>
> Baselining to done for Control and Configuration management.
> Like tracking all the variances from the plan and Change Management.
> Agile does not have this.
> 
> M.
> 
> On Tue, Feb 23, 2010 at 2:53 PM, <sharmila.patwardhan <at> ...> wrote:
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
pauloldfield1 | 1 Mar 2010 08:57
Picon
Favicon

Re: Scrum and Traceability

(responding to dsr)

> Is there any role for traceability in scrum? How can we handle
> links in scrum?

There are about 14 distinct reasons to have traceability, if you
count them all up.  Almost all of these are irrelevant if you are
working in an agile fashion, and most or all of the rest are covered 
by having a set of regression tests at 'green' (or not, as the case
may be).

Paul Oldfield
Capgemini

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
(Continue reading)

Permalink | Reply | 122 comments |
headers
Ron Jeffries | 1 Mar 2010 10:57
Picon
Favicon
Gravatar

Re: Re: Scrum and Traceability

Hello, pauloldfield1.  On Monday, March 1, 2010, at 2:57:00 AM,
you wrote:

>> Is there any role for traceability in scrum? How can we handle
>> links in scrum?

> There are about 14 distinct reasons to have traceability, if you
> count them all up.  Almost all of these are irrelevant if you are
> working in an agile fashion, and most or all of the rest are covered
> by having a set of regression tests at 'green' (or not, as the case
> may be).

I'd love to see a list of about 14 reasons to have traceability,
each with a few sentences on why with Agile one does not need them,
and/or why they are covered by regression tests ...

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
To gain knowledge, add something every day;
to gain wisdom, remove something every day.
  -- Lao Tzu

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/
(Continue reading)

Permalink | Reply | 121 comments |
headers
Franz Allan Valencia See | 1 Mar 2010 11:25
Picon

Re: Re: Baselining and Scrum

I'm curious about this one - "it may be useful". keyword there is "may be".

IMHO, if your experience in your current organisation seems to be pointing to using baselines (because tracking commit logs, issues in issue tracking system, sprint backlogs, etc are not enough), then go ahead and used baselines. How specifically will depend on why your current set up does not work.

However, if you're just assuming it may be useful, then that's a different story. A lot of things can be helpful, but some (or most) of them are addressing problems you probably won't encounter.

Personally, if you're just assuming it may be useful, then I suggest you don't do it. Just take note that it can be used in the future if you encounter the problems it is trying to solve. And if that problem does arise (which I don't think will have a significant cost), then use that process.

Btw, this also applies for other processes and tools as well. If a process/tool is solving a problem that has a low impact and/or is unlikely to happen, then why employ a costly process/tool?

And remember the basics, "Individuals and interactions over processes and tools." Be careful the processes/tools you introduce and verify if they actually help the team or if it hinders them :-)

Cheers,
--
Franz Allan Valencia See | Java Software Engineer
franz.see <at> gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

On Wed, Feb 24, 2010 at 1:40 AM, dsrkkk <dsrkkk <at> yahoo.com> wrote:
 



--- In scrumdevelopment <at> yahoogroups.com, Ron Jeffries <ronjeffries <at> ...> wrote:
>
> Hello, sharmila. On Monday, February 22, 2010, at 10:35:10 PM,
> you wrote:
>
> > Another thing about baselining was if the stories have a scope
> > change as per the baseline, in a time and material kind of
> > contract the customer has to agree to pay the additional cost or
> > bare the consequences of the change.
>
> Baselining assumes that change is bad. Agile assumes that change is
> good.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
>

What is meant by baselining? Baselining allows changes. Baselining provides the snapshot of data at a particular time. It may be useful in multi-user environment and large scale scrum projects.





__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 0 comments |
headers
Franz Allan Valencia See | 1 Mar 2010 11:42
Picon

Re: Re: How do I help my team be more agile?

I agree on this one. There seems to be a lot of habits to break, and breaking a huge habit would face a lot of resistance.

IMHO, start being agile on simple things first like working closely with your designers and testers. Take a sneak peak on what your designer has (even if it's not finished according to your organisation's standard), talk to him/her (it would be better if you can get your tester involved as well). Then try to verify early on (instead of waiting for x weeks/mos). Or if there's already a ton of things in the requirement already by the time you take a look at it, verify the items there one by one. You don't have to finish all at once before getting a feedback.

Also, you can try and do unit testing. That part is usually easy to set up as opposed to full blown automated acceptance testing.

Basically, just identify some small things that's wrong and apply agility to it.

IMHO, if you can't be agile on the small stuffs, then it's going to be hard being agile as an organisation :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see <at> gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

On Sat, Feb 27, 2010 at 10:46 AM, JackM <jack <at> agilebuddy.com> wrote:
 

...
Try baby steps, even one developer at a time. Get one developer on your side, get him to work with qa upfront to define acceptance tests. Get some early wins, this will help others to see the way.

Jack
www.agilebuddy.com
twitter.com/agilebuddy
blog.agilebuddy.com



--- In scrumdevelopment <at> yahoogroups.com, "Griner, Jennie" <jennifer.griner <at> ...> wrote:
>
> Some quick background, my group decided to implement an agile approach
> on our last release. Ignoring any work that was done before this
> decision was made, we had 13 month long sprints, followed by four
> additional months of panic mode testing and bug fixing. I had done my
> research on what I thought agile meant for us, and would try to bring up
> things that weren't really agile, and was ignored. Needless to say, we
> basically did a waterfall with some mini waterfalls in the middle (if
> you can even consider it that because we hadn't even fixed bugs as we
> came across them, they were all saved for those last four months).
>
>
>
> So, the powers that be have gotten together after a retrospective of
> that release and decided that things weren't agile, and we're going to
> actually be agile this time. However, it appears to me that they still
> can't get some of the older ways of doing things out of their systems.
> We still have to have the requirements for a story fully documented
> (though they did change the DoD to say "agreed on" rather than "signed
> off" and they did change the item regarding Use Case and User Interface
> to include the words "if needed."
>
>
>
> Management still insists on fully detailed test cases that can then be
> passed on to a tester on the regression team in later iterations, but we
> can't leave the job of writing it to the regression tester, so the test
> member of the team must complete this prior to the end of the sprint,
> even though we know that things could continue to change up until the
> end. This is after a test strategy must be completed along with test
> scenarios (high level test cases) for that sprint.
>
>
>
> As for bug fixes, it's hard to tell as we're halfway into our first
> sprint, and I don't think we've received a single build with the new
> code in it. The DoD does say that the bug fixes will be made, but it
> did for our last release as well. The team as a whole does seem to have
> made a commitment to follow the DoD much better this time, so that is a
> plus.
>
>
>
> But how do I approach some of these issues? I've asked for formal Scrum
> training (which no one in our group has received yet, which I think it
> part of the issue), and some training has been set up, but as far as I
> know, I am not going to receive it. I feel like I need to be heard, but
> at the same time I need to make sure that my duty to my Scrum team (as
> is currently defined) isn't skipped out on either. Am I just stuck with
> how someone else has decided things are?
>
>
>
> Jennifer L. Griner, MCP, MCDBA
>
> Quality Control Specialist, ProSystem fx Engagement
>
> CCH, a WoltersKluwer business
>




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 0 comments |
headers
Franz Allan Valencia See | 1 Mar 2010 12:00
Picon

Re: UML and Scrum

I like Agile Model Driven Development's approach to UMLs.

Basically (if I understood/am applying it correctly), the models that depicts that overview (business & architecture) are what usually are kept. These are mostly produced during iteration 0. While those that you produce via communicating to another person or to the team during actual implementation are usually the throw-aways.

But strictly adhering to the UML standards is not the point (you can even use something else other than UML). The point is communication (analogous to what DDD does for written/spoken language).

As for Scrum specifically, it does not mention anything about it. You may or may not use it, as long as your team is self-organizing :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see <at> gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

On Fri, Feb 26, 2010 at 1:17 AM, dsrkkk <dsrkkk <at> yahoo.com> wrote:
 

I am trying to know whether UML modeling is used for scrum projects.

dsr





__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 13 comments |
headers
George Dinwiddie | 1 Mar 2010 16:07
Favicon

Re: Re: Scrum and Traceability

Ron,

Ron Jeffries wrote:
> Hello, pauloldfield1.  On Monday, March 1, 2010, at 2:57:00 AM,
> you wrote:
> 
>>> Is there any role for traceability in scrum? How can we handle
>>> links in scrum?
> 
>> There are about 14 distinct reasons to have traceability, if you
>> count them all up.  Almost all of these are irrelevant if you are
>> working in an agile fashion, and most or all of the rest are covered
>> by having a set of regression tests at 'green' (or not, as the case
>> may be).
> 
> I'd love to see a list of about 14 reasons to have traceability,
> each with a few sentences on why with Agile one does not need them,
> and/or why they are covered by regression tests ...

As would I.  I've seen may people ask about traceability on this an 
other lists.  Not one of them has answered my questions about what they 
want to trace and why.  The best answer I can get is that it's "required."

  - George

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

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 86 comments |
headers
Steve Ropa | 1 Mar 2010 16:33

Re: Re: Scrum and Traceability

Brian: "Why aren't women allowed to go to stoning, mother?" 
Mother: "Because its *written* that's why!"
 
I see this discussion going the same direction as the baseline discussion.  The only reason I've ever seen for either one, and I am not making light of this reason, is because someone else requires it.  Whether it be the big boss on Mahogany Row who needs to see where things were and where they are going, or a project manager who has "learned over the years" that these artifacts are required.  What I haven't seen is any need for the actual development team to have traceability of anything in particular..

Sent: Monday, March 01, 2010 8:07 AM
Subject: Re: [scrumdevelopment] Re: Scrum and Traceability

 

Ron,

Ron Jeffries wrote:
> Hello, pauloldfield1. On Monday, March 1, 2010, at 2:57:00 AM,
> you wrote:
>
>>> Is there any role for traceability in scrum? How can we handle
>>> links in scrum?
>
>> There are about 14 distinct reasons to have traceability, if you
>> count them all up. Almost all of these are irrelevant if you are
>> working in an agile fashion, and most or all of the rest are covered
>> by having a set of regression tests at 'green' (or not, as the case
>> may be).
>
> I'd love to see a list of about 14 reasons to have traceability,
> each with a few sentences on why with Agile one does not need them,
> and/or why they are covered by regression tests ...

As would I. I've seen may people ask about traceability on this an
other lists. Not one of them has answered my questions about what they
want to trace and why. The best answer I can get is that it's "required."

- George

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



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 85 comments |
headers
matt gelbwaks | 1 Mar 2010 16:45
Picon

Re: Re: Scrum and Traceability

One of the best reasons for traceability is for planning, particularly in mature projects or projects close to release.  With traceability, my product managers can have a discussion with the team and when they say "I would like to change this requirement" or "I would like to modify that operational behavior", the team can draw the traceability diagram and let the PM know all the things that will need to be retested and validated and estimates can be made to determine whether there is adequate ROI for the change.  It becomes part of the "costing" for the new or changed features.

m

On Mon, Mar 1, 2010 at 10:33 AM, Steve Ropa <theropas <at> q.com> wrote:
 

Brian: "Why aren't women allowed to go to stoning, mother?" 
Mother: "Because its *written* that's why!"
 
I see this discussion going the same direction as the baseline discussion.  The only reason I've ever seen for either one, and I am not making light of this reason, is because someone else requires it.  Whether it be the big boss on Mahogany Row who needs to see where things were and where they are going, or a project manager who has "learned over the years" that these artifacts are required.  What I haven't seen is any need for the actual development team to have traceability of anything in particular..

Sent: Monday, March 01, 2010 8:07 AM
Subject: Re: [scrumdevelopment] Re: Scrum and Traceability

 

Ron,

Ron Jeffries wrote:
> Hello, pauloldfield1. On Monday, March 1, 2010, at 2:57:00 AM,
> you wrote:
>
>>> Is there any role for traceability in scrum? How can we handle
>>> links in scrum?
>
>> There are about 14 distinct reasons to have traceability, if you
>> count them all up. Almost all of these are irrelevant if you are
>> working in an agile fashion, and most or all of the rest are covered
>> by having a set of regression tests at 'green' (or not, as the case
>> may be).
>
> I'd love to see a list of about 14 reasons to have traceability,
> each with a few sentences on why with Agile one does not need them,
> and/or why they are covered by regression tests ...

As would I. I've seen may people ask about traceability on this an
other lists. Not one of them has answered my questions about what they
want to trace and why. The best answer I can get is that it's "required."

- George

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




--
Cheers,
       m


__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 7 comments |

Gmane