Feed aggregator

Scrum Versus Kanban: An Interview with Cory Foy

Agile Connection -

In this interview, Cory Foy speaks about his upcoming presentation at Agile Development & Better Software Conference East, why choosing Scrum or Kanban is similar to climbing a mountain, how organizational change is all about experimentation, and why companies should use Innovation Games.

Sense, Create, and Respond to Change

Rally Software - Agile Blog -

Last week we looked at how today’s global markets require new ways of doing business, so that you can respond quickly to threats and opportunities. We showed you why it’s not enough simply to implement Agile practices into your development shop; you need to build agility into the culture and behavior of your entire organization. And we defined agility as the integral characteristic that allows you sense, create, and adapt to change -- quickly and confidently.

The compelling driver of agility is the speed and impact with which innovations are changing entire industries -- what many refer to as disruption. McKinsey advises that the companies that have survived and thrived amid disruptive change are those that have developed capabilities for speed, transformation, and innovation:

“ … these companies built the organizational capacity and agility required to lead during the disruption. They made big shifts in leadership focus and major changes to resource allocation, and they developed a faster organizational clock speed and leaner cost structure.”

Lest you think disruption is something that hits you like a freight train, one you see coming from a mile away, consider the phenomenon of dematurity: this is what happens when companies in an established industry (say, healthcare, automotive manufacturing, or power) experience a series small innovations over a short period. Over time these “mini-disruptions” add up, and in the aggregate they can cause radical changes to the industry.

“It is all too easy to be caught off guard—to ignore the small changes that appear one by one, to fail to believe they will affect you, and to end up at the tail of the wave, outpaced by competitors who saw the possibilities earlier,” says PwC strategy and innovation advisor John Sviokla.

“The solution lies in gaining better sensitivity—in other words, improving your ability to recognize and respond to the signals of incremental change."

Get Outside the Building

To sense change, your entire organization needs to be attuned to shifts in the market. You need to leave the office, in a literal and figurative way. You need to gain understanding of the technology driving change and innovation, and you need to regularly take the pulse of the customer.  

As you sense change, your organization must be prepared to both “create” opportunities and “respond” to threats. This is where speed and agility come into play.

Speed is paramount. Information Week’s 2014 Strategic Survey of CIOs cites speed of execution as their top concern. Market windows are incredibly tight, and big companies face competition from nimble start-up competitors.

Agility is what gives companies the ability to move quickly and with confidence. It’s the product of having a disciplined approach to managing change. Agility isn’t a one-time thing; it should become part of your organization’s DNA.

Where to Start

We’ve identified three kinds of agility you need to build across your organization.

Your foundation is execution agility, where speed and performance in your software development help you deliver value faster and gain a competitive advantage.

Then you need to connect your execution with your strategy. Portfolio agility lets you create opportunities with focus and insight into your organization’s highest-value initiatives.

At the broadest level, business agility builds responsiveness into your company culture. You’ll have the confidence to create change through lean innovation and the resilience to respond to change however it impacts you.


Keep learning. Get a copy of the Business Agility Survival Guide.

Rally Software

Agile: Don’t Worry, It’s Natural

Agile Connection -

Although the idea of repeatedly exercising the full development lifecycle on smaller chunks of the requirements is newer to the software industry, it isn’t at all new to many other aspects of life and nature. We have been agile practitioners for quite some time, and the software development industry is just catching up. John Ryskowski addresses a few examples.

Cancel Your Executive Status Meetings (Do This Instead)

Rally Software - Agile Blog -

Last week I met with a strategy leader for an Australian financial services organization, who was trying to work out how to bring his executive team together on a regular cadence to align around strategy. He’d built a great Kanban board to visualize the large strategic projects the organization was pursuing -- sort of an executive-level roadmap -- and wanted some ideas for how to bring execs together around it.

In my role I spend a lot of time promoting a quarterly, one-day, Agile business steering meeting that brings leaders together to align on strategic priorities and harmonize their quarterly tactics. I think that such a meeting really is the heartbeat of business agility at scale. But once you’re aligned around your intentions for the quarter, how do you steer within the quarter?  

I recommend thinking about three cadences. These include:

  1. A weekly, extended management “impediments” meeting
  2. A weekly executive staff meeting
  3. A bi-monthly metrics meeting
1. Weekly Extended Management Impediments Meeting 

This Scrum of Scrums (SoS) is a short standup meeting involving your extended management team, usually 20-40 people depending on your organization’s size. The purpose of this meeting is to bring junior and senior executives together across departments to raise and resolve impediments encountered on any top priorities.

This is not a status meeting, and indeed, if you have any meeting reporting red / yellow / green status on your tactical initiatives, cancel it right now; you’re wasting time. Initiatives are often green until they’re suddenly red, and by then it’s too late to do anything. Huge amounts of waste goes into producing beautiful status reports that obscure what’s actually going on.

We run the SoS meeting standing in two concentric circles. The inner circle (close to the conference table) is for anyone with important news or significant impediments that they need help with; they’re the ones who speak. The outer circle (against the wall) is for everyone else: they only listen, unless they want to offer help with an impediment. This meeting often lasts just a few minutes, and never more than 30. The group leaves when the inner circle is done and all impediments have been managed.  

an example of an executive meeting format with concentric circles

It can help to track the readouts from this meeting on a simple impediments board, logging recent results, issues, and actions, so that when people walk into the meeting they can quickly recall the context of the last meeting without taking up meeting time.

Just like team-level Scrum, a meeting like this needs a facilitative leader who can keep people focused, handle distractions, and help the group move to action. But at this level, your facilitator needs to be comfortable interrupting senior executives who are rambling. This requires a tricky balance. It can help to ask the group explicitly, “Do I have your permission to facilitate so we can get to results quickly?”

2. Weekly Executive Staff Meeting

It usually makes sense to hold the SoS meeting just before your standing (closed) executive staff meeting, because it gives your senior leadership team the pulse of the issues before doing a deeper dive on their own work. If you’re doing a meeting like this, keep it. If you’re not doing it, start one.

3. Bi-monthly Metrics Meeting

This meeting is a deep dive on key metrics for the business, and may last 1-2 hours. It usually begins with key financial results (revenue, cash flow, and whatever other macro business results make sense for your organization.) Then it dives deeper into your business improvement metrics.

If you’re doing strategy deployment well, you have tactics for improving your business results and leading indicators that tell you whether you’re making progress towards achieving your results. If you’re using a balanced scorecard, all this should be sounding familiar.  

On a regular two- or four-week cadence, your senior leaders should be able to dive deeply into these leading indicators so you can sense whether you need to steer your tactics. If you expected your pipeline to be twice as big in the current quarter, or if you’re seeing a growing backlog in a specific part of your business, you can take action to adapt in the coming business steering meeting. The metrics cadence gives you time to get ahead of this work, so you can steer tactically during your quarterly meeting.

Bringing It All Together

The quarterly meeting is essential to building alignment at this level; once you’re doing it, these three regular meetings enable to you to steer and deliver on your tactical plans.  

What’s the heartbeat of business agility for your organization? 

Learn more about business agility: why you need it, and how to get it. Find out more about how good meetings help you take the pulse of your organization.

  Alex Pukinskis

The Scrum Guide: An Interview with Jeff Sutherland

Agile Connection -

In this interivew, Dr. Jeff Sutherland, one of the inventors of Scrum, talks about a new community website, ScrumGuides.org. He covers the backbone of the Scrum concept, how Scrum can increase productivity, how organizations fail to implement it properly, and how Scrum is like a martial art.

I am a defender of the oppressed

Alistair Cockburn -

I am a defender of the oppressed,

not those with burkas who are so oppressed
(not that all with burkas are oppressed),
for they have champions, however inadequate, however still in need,

not the poor, nor the handicapped, nor the white, nor the black,
the red, the yellow,
the sick, the dying, the new-born, the unborn,

for they all have voices,
still not sufficient, still in demand;

but for the artists,
the musicians, the mimes, the dancers,
the people without words,
for whom words are not a thing,

antagonized, minimized, oppressed
by philosophers,
lawyers,
rule-makers,
the system,
who think words are all,

who use words to declare that words are all,
and those without words aren’t.

While the dancers, the musicians, the sculptors, the mimes,
dance, sing, sculpt and play their experience of the world,
that rich, so much wider world they inhabit,
without words,

so richer than the impoverished world
of the legalized words
that imprison them,
remove the validity of their world,
declare them empty,

while the painters, the drummers, the dancers
see, feel, hear, move, the vastness of the world
without words.

I am words, defending them.

(© 2014, Alistair Cockburn)

Mitigating Team Hazards without a Typical Scrum Product Owner

Agile Connection -

A good product owner should be collaborative, responsible, authorized, committed, and knowledgeable. But what do you do if yours doesn’t exemplify these characteristics? This article aims to showcase mitigation plans that can be effective for overcoming Scrum violations due to the fact that you’re not working with a typical product owner.

Scaling Agile Your Way: How to Develop and Implement Your Custom Approach (Part 4 of 4)

VersionOne Agile Management Blog -

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.  In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (Tables 1-4 of Part 1).   I also presented a brief overview of various popular agile and lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.

Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.  SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS.  The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective.  The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot.  The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.

In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The root cause is likely to be one of these two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate their understanding and commitment to the success of scaling agile.

2.  Arising from the market and business environment of your organization.  These pressures cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment some of the scaling agile framework practices with your own custom practices, while retaining the practices from the framework that are still applicable.

The journey from Unfit or Challenge Zone to Sweet Spot is uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but may still have a few areas in the Challenge Zone to address.

In this final part of my series, I explain a very important challenge for Scaling Agile Your Way.  It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways.  I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.

The Scrum at Scale framework provides a general language for talking about how to scale Scrum.  At its roots, Scrum is an object-oriented framework.  Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs.  Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time.  Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.

Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:

1.  Team-Level Scrum Process
2.  Strategic Vision
3.  Backlog Prioritization
4.  Backlog Decomposition and Refinement
5.  Release Planning
6.  Release Management
7.  Feedback
8.  Continuous Improvement and Impediment Removal
9.  Cross-Team Coordination
10. Metrics and Transparency

As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs.  It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs.  The details of implementing each module should be left to each entity, as the implementation details are expected to be different.  Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.

SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not.  Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations.  This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe.  Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)?  Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints). 

Table 12:  Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

 

Table 13:  Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 14:  Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Customization needs and opportunities for the MAXOS framework

These will arise mostly in the context of implementing its advanced engineering practices of:

  • Code contribution
  • Automated testing
  • Continuous integration
  • Feature switches
  • Continuous delivery
  • Collecting and analyzing automated user feedback
  • Making use of cloud computing facilities on a massive scale, etc.

There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment.  I will not elaborate on MAXOS customization here.

How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?”  Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind?  I would love to hear from you on these questions or any aspect of this four-part blog series, either here, by email (Satish.Thatte@VersionOne.com), or on
Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 3: Scaling Agile Your Way:  Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS

No More Business as Usual

Rally Software - Agile Blog -

When the S&P 500 index was created in 1957, the average expected lifespan of a company on the index was 61 years. By 1980 that lifespan had been cut in half, and in the coming decade it likely will be halved again. What used to be a health index for stable companies is now a thermometer for the fluctuating temperatures of disruptive markets.

The S&P is just one indicator of the evolving environment for businesses. Markets are now global and highly responsive. Competition moves at startup speed. Operational efficiency isn’t a nice-to-have, it’s a necessity. Customers, and their expectations, hold more sway than any executive. And at the heart of all these changes is a technology backbone, accelerating both the opportunities for innovation and the impact of competitive threats.

Adapt or Die

Woolworth’s. Kodak. Blockbuster. Borders. The list of companies that couldn’t survive in this new environment is long and growing.

“Big companies that fail to innovate risk extinction,” says the BBC. “That's the stark truth in the era of 'digital disruption.'"

Being a big fish doesn’t make you immune and being a small fish doesn't make you competitive; disruption will affect nearly every business in some way, it's just a question of how ... and when.

Agility: The Competitive Advantage

What makes some companies survive – and thrive – in this kind of environment, and how can you become one of those companies?

Companies that successfully navigate today’s competitive markets know how to sense, create, and respond to change, and they can do it quickly and confidently.

Agility throughout an organization can ”spell the difference between being severely disrupted, or turning the disruption from a threat to a competitive advantage – an opportunity to develop new products, service, markets and business models to help propel the company into the future.”

These companies don't just practice agile in their software development; they are agile businesses

  • They improve and scale their software development performance so they can deliver more value to customers, faster.
  • They connect their software development performance to business strategy, building flexible portfolio management that adapts quickly to market changes and optimizes for business value.
  • They invest the dividends of their performance gains in market-leading innovation, running experiments and getting fast customer feedback.

Learn how to build agility into your company’s DNA. Download the new Rally Business Agility Survival Guide and get started.

Rally Software

Myth 34: You’re Empowered Because I Say You Are

Agile Connection -

Do your managers truly own their decision making or are they only "empowered" to come to you for approval of every idea and dollar spent? If you don't trust your team leaders to make decisions, how can you expect stakeholders to? Setting boundaries and defining expectations are two ways to empower managers and encourage initiative, giving them the opportunity to gain your trust.

Re: Agile contracts

Alistair Cockburn -

Nice round up.

Payment per story points seems the best to me.

I like the idea of paying 5% if delivered on time. That could be a bonus split for the team.

Thanks for sharing!

-by MarcoBarbosa on 4/29/2010 at 5:33 PM


I am still partial to #1. I do not believe in charging for time, only results. Billing by the hour is inherently unethical.

-by Mark Richman on 4/30/2010 at 9:43 AM


@Mark — charging for time is not unethical, it’s just a kind of agreement. It’s appropriate when the customer can’t or won’t define precisely what they want in advance.

-by xpmatteo on 6/24/2010 at 10:53 AM


I read somewhere that we should have a higher price per story point in early sprints and a lower one in late sprints (since the idea of Agile is to deliver the most value early). Does anyone have some experience with this ? Do you know about any formula to put this in place ?

Regards,
Chris

-by Chris on 7/7/2010 at 6:27 AM


Good question, Chris … I have an idea, just for fun – how about reversing that logic and charge less for early sprints and more for later sprints, to entice customers to get their value quicker, up front, and to quit the product development sooner, as the value/feature starts to drop off? Encourage the behavior we want to see?

Any thought? :)

-by Alistair on 7/7/2010 at 11:10 AM


I am battling with one central problem in agile: how do you remain “agile” and open to change when you’re working against a fixed budget and defined scope, and a customer who is not a “software person”.

We use an adapted version of SCRUM for web development, which is part-software and part-design. Our customers have only a limited interest in being involved in the project. They want x by x date. But they also want to make changes along the way.

So do you baseline the project against the original scope document? And then measure each change impact on the budget?

It’s driving me kind of nuts — how can you merge an agile process with a non-agile budget?

-by Jarred Cinman on 11/25/2009 at 1:38 PM


I think Earned-value and burn charts (discussion: Re: Earned-value and burn charts) and http://en.wikipedia.org/wiki/Project_triangle might help you.

Also: don’t be afraid to say “no” to the customer. Every time you say “yes” to the customer you lose a bit of control over the project. If you say “yes” too much the project will spin out of control.

-by Floyd on 11/26/2009 at 7:18 AM


Thanks, could be a nice data for my benchmarking in the subject of CM.
LSS Expert – IECOACHdotCOM

-by Johan Wennermark on 9/21/2011 at 2:55 AM


bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.

-by Ken on 11/28/2011 at 3:21 PM


bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.

-by Ken on 11/28/2011 at 3:51 PM


I have participated in a Swedish market initiative to establish general terms for agile projects. I have in this work introduced a new term called “Spare timeboxes” (or spare Sprints). The purpose of these are to allow limiited scope creep. Number of spare timeboxes needed in a project depends on the uncertainty of requirements.

It’s also possible to agree incentives models based on use of spare timboxes.

A preplanning would require a definied timebox sequence, also including thes spare timeboxes. Based on this sequennce and assumed resource utilization it’s poosible the agree a goal price.

-by Lars Wendestam on 2/6/2012 at 8:52 AM


I have recently worked out one of these ideas in very much detail (a book published by Wiley & Sons with the title “Agile Contracts”) with the aim to make this topic chewable for all involved parties. Looking at Alistair’s list, it is quite clear to me (the geek) but in the last years I have seen cultures clashing at these quite obviously interesting concepts… meaning the classical ”... look I do not need that, as I am anyway telling you in advance what you should do…” (told by a legal or procurement person with its IT colleagues already shaking the head) or my favorite ”... it works fine now, why shall we change…” (from the procurement guy neglecting the real performance of the recent projects….

-by Andreas Opelt on 10/13/2014 at 9:47 AM

Re: Sampler of good and bad use cases

Alistair Cockburn -

I am a bit confused about which the good and which the bad examples are.

I assume the black ones (i.e. the first three) and the ones with smilies are good?

Best regards,
Thomas

-by Thomas Schandl on 4/8/2009 at 8:50 AM

The ones with mistakes say “Mistakes” right above the use case title, and the good ones have the smiley faces. Hope that helps, Alistair -by Alistair on 4/8/2009 at 5:00 PM
Hi Alistair,

okay, so then all of the ATM use cases are mistakes.

I’m not sure how the ATM UC should be modelled ideally, or what exactly is wrong with some of the bad examples – but I already ordered your book, so I’ll learn it soon ;-)

bye,
Thomas

-by Thomas Schandl on 4/9/2009 at 4:38 AM

Right. Since I teach the ATM in my class, I don’t publish the preferred writing of that use case – either work it out from the book or come to the class :). So sorry. Alistair


Hi Alistair,

Do you regard data formats as requirements? I cant decide if they are a what or how (design).

If so where do you place data requirements in your requirements catalogue?

Thanks,
Mark

-by Mark on 7/20/2009 at 12:05 PM

Data requirements are Chapter 4. Use cases are Chapter 3. (euphemistically speaking, of course) :) Alistair

-by Alistair on 7/23/2009 at 4:48 PM


This list of good and bad use cases is not helpful at all.

Don’t just present a list of good and bad examples. Tell the reader instead why an example is good, why one is bad, and how a bad one could be improved.

-by Roland on 9/16/2010 at 4:07 AM

Hi, Roland, The discussion of what’s right, what’s wrong, how to repair, are in the books Patterns for Effective Use Cases, Writing Effective Use Cases, and in our various lectures and classes. This list is not intended as a tutorial, it is intended as a showcase of use case examples for people to inspect and discuss. If you wish, you can start that discussion by suggesting what is wrong with some of these, and how to repair them. Alistair


I bought Cockburn’s book Writing Effective Use Cases. What a BIG mistake… Its garbage… A total waste of money. Its poorly written with disjoint examples and poor explanations.

Its only matched by his arrogance above where he answers people questioning why he doesn’t give more info with “buy my book to see the answers”....

My recommendation: Look to another source….

-by mike on 1/26/2011 at 4:21 PM


Thanks for sharing, Mike. :). Alistair

-by Alistair on 2/8/2011 at 3:29 PM


Hi, this list was not helpful at all. In fact I am more confused then before I read this information.

I am really trying understand UML for my graduate course. This was written to appeal to UML experts and not students.

-by Sherri on 10/7/2011 at 10:11 PM


Yeah, gotta throw us a bone here Alistair…there are four ATM use cases with mistakes, maybe explain why one of the four is wrong. Market to us a bit more with your knowledge and we’ll be more inclined to buy the book. I’m new to use cases so this page isn’t terribly helpful…I’ll keep looking through the site though.

-by RS on 10/31/2011 at 6:51 PM


OK, the “book flights” cases are more informative. I advise less-experinced viewers of this page (like me) to look at those.

-by RS on 10/31/2011 at 6:56 PM


re: Mike’s discontent with Writing Effective Use Cases

Just in case someone reads these remarks and takes Mike seriously, please be aware that he is among a distinct minority. The vast majority of readers, self included, disagree, as witnessed by the book’s popularity and overwhelmingly positive reviews (e.g., as of 25 Oct 2012, it has an average 4.5/5 review among 55 reviewers on Amazon).

No disrespect intended to Mike; he is entitled to his opinion if he found the book to be unhelpful. Most readers on record disagree with him, however.

-by Steve Swope on 10/26/2012 at 12:55 AM


Thanks for the examples. I am a BA in a small team and it helps to see how some folks might approach use cases incorrectly so I can avoid the same mistakes. I think the negative feedback is due to individuals not yet understanding use cases, at least not formal use cases. Your methods and approaches work very well! I used your approach to build requirements for a custom system with a large team of developers/stakeholders and it was a success.

-by syz on 2/28/2013 at 11:23 AM


Thanks for the examples. I am a BA in a small team and it helps to see how some folks might approach use cases incorrectly so I can avoid the same mistakes. I think the negative feedback is due to individuals not yet understanding use cases, at least not formal use cases. Your methods and approaches work very well! I used your approach to build requirements for a custom system with a large team of developers/stakeholders and it was a success.

-by syz on 2/28/2013 at 11:29 AM

Thank you for that kind note! Alistair

Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 4:30 AM


Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 5:48 AM


Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 7:27 AM

Pages

Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator