Agile

PM 101: Dealing with Team and Customer

Scrum Alliance - Mon, 05/14/2012 - 15:38
Agile processes are gaining in popularity, which means many project managers are following them for the first time. Based on my own experience, I've developed a sort of primer for PMs starting out on Agile projects. The key points are as follows: ...
Categories: Agile

From the Command Post

Scrum Log Jeff Sutherland - Tue, 05/08/2012 - 21:27


Categories: Agile

An Example of a Great User Story

Scrum Log Jeff Sutherland - Tue, 05/08/2012 - 15:41

From Alex Sutherland. No more need be said.


Categories: Agile

Fira Palace Guest Room Request

Scrum Alliance - Mon, 05/07/2012 - 21:38
Categories: Agile

Empowerment: The Missing Ingredient for Scrum Teams

Scrum Alliance - Mon, 05/07/2012 - 21:28
We all understand that Scrum teams should be self-managed and self-organized. Empowered is the commonly used term, because without empowerment it's difficult for self-management and self-organization to happen. I've worked with many teams that ar...
Categories: Agile

HICSS-46 CALL FOR PAPERS

Scrum Log Jeff Sutherland - Mon, 05/07/2012 - 08:27
Get your papers ready for the January 2013 HICSS conference (in Maui)!  The Agile and Lean Organizations track will be one half day during the 4-day conference. HICSS is a conference with a wide-variety of researchers (not just software) interested in system-science—how things get invented, organized and completed. You'll have many opportunities to socialize with other speakers (barbecues, beaches and good food).  The papers are IEEE published so it's a good opportunity to get your work out to the world.  I hope you can join us.
Location Grand Wailea Maui
January 7-10, 2013 (Monday-Thursday)
Agile and Lean Organizations Mini-Track Agile and lean approaches promote iterative product releases and pull risk-reduction earlier in product development. Characteristics include: cross-functional teams, rapid outcome testing (such as automated testing in software), continuous quality monitoring and deployment, pairing (for software, pair-programming), bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test market hypotheses and rapidly adapt to discoveries.  Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction, deeper customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient resource utilization.
Advocates believe that sustainably agile/lean organizations must demand technical excellence everywhere (not just in software), promote individual and organizational change, organize knowledge, train employees in agile and lean philosophies, and optimize the whole value chain from concept to cash.
We seek research papers and experience reports that describe how agile development and lean product management affect organizational systems and outcomes. How do agile development and lean product management interact? How do organizations restructure to support these philosophies? When they do not restructure, what happens? How do markets respond to rapid iterations and end-user experimentation?
HICSS conferences are devoted to the most relevant advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Accepted papers may be theoretical, conceptual, tutorial or descriptive in nature. Those selected for presentation will be included in the Conference Proceedings published by the IEEE Computer Society and maintained in the IEEE Digital Library.
How to Submit a Paper Follow Author Instructions posted on the conference web site: http://www.hicss.hawaii.edu/hicss_46/apahome46.htm.
  • Select the correct track: “Agile and Lean Organizations” or “Agile/Lean Startup Organizations”
  • HICSS papers must contain original material. They may not have been previously published, nor currently submitted elsewhere.  All submissions undergo a double-blind peer review process.
  • Abstracts are optional, but strongly recommended. You may contact the Minitrack Chair(s) for guidance or verification of content.
  • Submit a paper to only one Minitrack.  If a paper is submitted to more than one minitrack, then either paper may be rejected by either minitrack without consultation with author or other chairs. If you are not sure of the appropriate Minitrack, submit an abstract to the Track Chair(s) – see names and contact information below. for determination, and/or seek informal opinion(s) of Minitrack Chair(s) before submitting.
  • Do not author or co-author more than 5 papers.  This means that an individual may be listed as author or co-author on no more than 5 submitted papers.  Track Chairs must approve any names added after submission or acceptance on August 15.
Important 2012 Deadlines for Authors DateDescription June 15Submit full manuscripts for review as instructed. The review is double-blind; therefore, this initial submission must be without author names. Aug 15Review System emails Acceptance Notices to authors. It is very important that at least one author of each accepted paper attend the conference. Therefore, all travel guarantees – including visa or your organization’s fiscal funding procedures – should begin immediately. Make sure your server accepts the review system address https://precisionconference.com/~hicss. Sept 15SUBMIT FINAL PAPER. Add author names to your paper, and submit your Final Paper for Publication to the site provided in your Acceptance Notice.  (This URL is not public  knowledge.) Oct 1Early Registration fee deadline. At least one author of each paper should register by this date in order secure publication in the Proceedings. Fees will increase on Oct 2 and Dec 2. Oct 15Papers without at least one paid-in-full registered author may be deleted from the Proceedings and not scheduled for presentation; authors will be so notified by the Conference Office. Cancellation and Refund Policy   All conference cancellation requests must be in writing.  A fee will be charged for cancellation of registration after Oct 15, at which time the paper is subject to withdrawal from the Proceedings.  There is no registration refund after Dec 1.  Cancellations for accommodations must be handled directly with the hotel.
HICSS-46 TRACK CHAIRS Software Technology
Gul Agha  agha@cs.uiuc.edu
Rick Kazman  kazman@hawaii.edu
Agile and Lean minitrack co-chairs Gabrielle Benefield
Evolve Beyond Limited
gbenefield@evolvebeyond.com

Dan R. Greening
Evolve Beyond LLC
dgreening@evolvebeyond.com


Categories: Agile

ScrumPlop has Begun

Scrum Log Jeff Sutherland - Sun, 05/06/2012 - 20:17


Categories: Agile

Google Automation of my QA Strategy

Scrum Log Jeff Sutherland - Sun, 05/06/2012 - 15:07
I have consistently found in my own companies and Openview Venture Partners companies that I coach that carefully prioritized implementation of acceptance tests produces higher quality faster than anything I have seen.

An Open-E in Poland they implemented continuous integration and immediately increased the velocity of over 50 developers by 20%. The next step was to improve the quality of their open source network storage server software so it could be released faster with fewer support problems. The software had to run on 80 different hardware platforms and needed thorough acceptance testing by a quality assurance team after development had completed a release. This acceptance test phase took 4-6 weeks per release.

I told them to proritize the problems encountered by the quality assurance team and implement tests in the build process to prevent these problems from ever appearing again. After 3 weeks of work by one developer there were 130 tests were running in the build process. The next release cycle cut quality assurance to 2 weeks and reduced support calls from the field by 50% saving millions of euros of development time and generating millions of euros in increased sales. Nothing I have seen works better than this.

Google has developed a brilliant automated strategy called "Bug Prediction" which does essentially the same thing. Seems like every team should be doing something like this.

Bug Prediction at Google
What's the problem?
Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.


For details click here ...


Categories: Agile

Agile Planning - Fighter Pilot Meets Solo Sailor

Scrum Log Jeff Sutherland - Sat, 05/05/2012 - 14:15
Recently I visited Hank de Velde on his boat that he uses to sail solo around the world with Rini van Solingen, original author of "The Power of Scrum." Hank and I had similar ideas on planning for high risk adventures.


Categories: Agile

Scrum Alliance Newsletter: May, 2012

Scrum Alliance - Wed, 05/02/2012 - 15:13
Categories: Agile

Software in 30 Days is Out!

Scrum Log Jeff Sutherland - Tue, 05/01/2012 - 17:54

The official publication of "Software in 30 Days" is May 1. The book is a collaboration between the two creators of Scrum, Jeff Sutherland and Ken Schwaber. The goal of Scrum is to actually have working software at then end of each Sprint, which should be 30 days or less. Working software means tested, integrated, and ready to ship if necessary! This book shows you how it's done. It shows you how you can implement Scrum in your company, and how to improve the Agile practices you are already using. From the introduction:

We, Jeff and Ken, have been in the software industry, collectively, for seventy years. We have been software developers, managers in IT organizations and software product companies, and owners of both product companies and service organizations. More than twenty years ago, we created a process that lets organizations deliver software better. Since then we have helped hundreds of organizations do the same. Our work has spread farther than we have ever imagined possible, being put to use by millions of people. We are humbled by the extent of its adoption, and we are awed by the feats people have used it to accomplish.  This is not the first book we have written on the topic of building software. It is, however, the first book we have written for people who do not themselves build software. This book is instead for leaders within organizations that depend on software for their survival and competitiveness. It is for leaders within organizations that can benefit from developing software rapidly, incrementally, and with the best return on investment possible. It is for leaders who face business and technological complexity that has made the delivery of software difficult. We have written this book so that these leaders can help their organizations achieve these goals, enhance their internal capabilities, improve their product offerings, and more.  This book is for CEOs, executives, and senior managers who need their organizations to deliver better software in less time, with lower cost, with greater predictability, and with lower risk. For this audience, we have a message: You may have had negative experiences with software development in the past, but the industry has turned a corner. The software profession has radically improved its methods and its results. The uncertainty, risk, and waste to which you are accustomed are no longer par for the course. We have worked with many software organizations
that have already turned the corner; we want to help you do so, too.  The book is available at Amazon and Barnes and Noble, in print and e-book versions. The print version is also available at Powell's.

Update: Can't believe I forgot it, if you're in the Netherlands, here's the bol.com link. Also available on Amazon.co.uk and Amazon.co.de. Thanks @scrumnl!


Categories: Agile

Change. One Person at a Time. Starting with You.

Implementing Scrum - Tue, 05/01/2012 - 09:22

It’s been a while since I have written a blog posting and I am currently spending a lot of time on Twitter and FaceBook.

Is blogging “dead”?

I don’t think it is, but is is very different way to communicate with people on a large scale.

Or is it?

Here I can publish as much (or as little) as I want with no limitations of 140 characters and stay very focused on Scrum and implementing this change in organizations.

And this scares me.

I travel a lot and work with so many incredible people around the world.

And.

People I have never met “follow” me in various places and for some reason follow what I write (and either love me or hate me, and I am OK with that).  I love sharing my experiences with you.  Right or wrong, they are my experiences and I know sharing them helps some people (and pisses off others).

When I look at the sheer number of people who have been impacted by this blog and our little comic strips in the past, it almost overwhelms me.

OK.  That’s bullshit.  It does overwhelm me.

Then, I am reminded.

I am not writing “for the masses”.

I am writing for you.

Or more specifically… TO you.

You.

One person.  An individual.  Not dozens, or hundreds, or thousands, or more (eek).

One person.

You.

I enjoy the style of me almost being able to “sit down” and have a conversation with you, imagining your responses to what I convey here and taking you down a windy road together with me — and there usually is something to think about when I end the posting.  It’s not for everyone, but this is an important medium for me to be able to do this with you.

I am also being reminded that change cannot happen in an organization overnight.

It has to happen starting with one person.

You.

Or… for me to take more responsibility… I have to accept change in me.

Stop trying to change the world.

Or your organization.

Or your team.

Focus on you.

The rest will follow.

Good luck!

Now… what can we do together as the next step?

Not “everyone.”

You.  And me.

 

 

Categories: Agile

Bring the Customer Along

Scrum Alliance - Fri, 04/27/2012 - 15:59
Recently I wrote an article with a rhetorical question for a title: Are Customers Ready for Agile? The idea stemmed from the fact that software development organizations have followed Waterfall methodology for so long that they h've ...
Categories: Agile

Maximizing the Value of Your Stand-up

Scrum Alliance - Fri, 04/27/2012 - 15:56
Over the last several years, I've been both a participant and a facilitator in many different stand-ups. As we know, the true value of the stand-up lies in the team's ability to continually strive toward the commitment for the current sprint cycle. The stand-up isn't a status report, yet often it becomes easy for team members to slip into a pattern of providing status-related information. I've used the time-honored stand-up approach for a while now, but I've often thought that a mature team could take these 15 minutes to a different level as it continues to evolve using Agile/Scrum.
Categories: Agile

Annual planning (not) by a cookbook, Part 2: “Guess Who’s Coming to Planning?”

Rally Software - Agile Blog - Fri, 04/27/2012 - 15:16

Welcome back to my series on Rally’s process for annual planning.

In the first post of this 4-part series about our planning, I offered you a glimpse into how we conducted some of the initial planning Iteration approach: from executive visioning through departmental ORIDs into deep preparation for the Iteration 3: the planning meeting. We chose to act as chefs in our approach versus follow a recipe.

Our annual planning has iterations

To reset the stage a bit, let me give a high-level view of our overall planning approach. Think about 5 iterations (not levels, iterations) of planning. We kicked off the annual planning through an executive offsite as our Iteration 1. The outcome of this iteration was a set of proposed Mother Strategies. (To learn about our use of Mother Strategies, checkout Part 1 of this series.) This was followed by Iteration 2: departmental ORIDs. I then touched into the preparation we asked of participants, our customer guests and our team of three facilitators for the 2-day meeting of annual planning, Iteration 3. Iterations 4 and 5 wrapped up the overall planning for the year by setting our cadence for continuous steering throughout the company.

Time for the planning meeting sessions to begin!

As the actual annual planning meeting approached, we stepped up the details of the facilitation processes that would guide the two days of planning. This Iteration 3 of planning included pre-reading as part of the iteration: Escape Velocity by Geoffrey Moore. Moore’s book about applying Horizons 1,2, and 3 in order to “free your company’s future from the pull of the past,” set the stage for all participants in the 2-day planning event. We drew upon Moore’s advice as a guide for our language and our very purposeful intentions for the year and beyond.

Build it and they will come–inviting guests to our “dinner”

It is this Iteration 3 event to which we invited our customer guests. Wow! We had never invited observers to our annual planning before. But we knew we wanted customers to see how we work, gather their feedback, and hopefully give them takeaways for their own agile organization planning. In morning sessions on the two days, we engaged over 60 Rally employees representing their teams. They were guided by 2 main facilitators and 2 assistant facilitators. For these large sessions, the facilitators prepared several weeks in advance to ensure the room provided guidance for all aspects of the meeting. In particular, we posted the purpose and a very detailed agenda. This helped everyone in the room understand the work at hand.

Afternoon sessions had a smaller gathering and concentrated on what had been learned and discussed in the morning sessions. The sessions were guided by 2 different facilitators. The 25 people in the afternoon represented the extended management team. Our guests were also present as observers. Yes, they saw and heard everything!

In the first morning, the executive team provided a review of their work on proposed Mother Strategies. The larger group of Rally employees created:

  • 23 departmental readouts captured on a large wall chart created in the morning
  • surprises, risks, dependencies, and recommendations brainstormed and captured in an affinity grouping chart about all the readouts
  • votes from all 60 attendees with regard to their reactions to the 5 Mother Strategy proposals that had emerged from the executive offsite

Our board of 23 departmental readouts






Mother Strategies–trust and safety in the 60-person voting step

We felt strongly about protecting each attendees anonymity as they evaluated the Mother Strategies. as defined in Pascal Dennis’s book “Getting the Right Things Done.” You can also checkout more in Part 1 of this series.) We wanted people to be able to make tough recommendations about the Mother Strategies without influence from others. Trust and safety were critical for the voting to be truly candid. Our anonymous voting system used colored cards and baskets. Each of the five proposed Mother Strategies had a basket into which people placed one of three possible colored cards:

  • Green card = “We need this Mother Strategy this year.”
  • Yellow card = “I don’t care whether we do this Mother Strategy or not.”
  • Red card = “We should not have this as a Mother Strategy for this year.”

Everyone voted on every strategy. They were also invited to write comments on the green/yellow/red small cards to explain why they had chosen a particular color.

During lunch, the team of facilitators counted all the cards for each Mother Strategy. We then used a bar chart to reveal: how many green vs yellow vs red cards each Mother Strategy received. And, we glued some of the cards with comments to a wall chart to show insights from the group. We wanted to provide feedback in both a quantitative and qualitative way.

Always close with a retrospective

Before the morning session was completely over, the facilitators team made sure the group could provide feedback on the meeting. Participants populated a mood chart about each part of the morning’s agenda in the following way: were you glad we had the agenda item; did it not really impact you one way or another; or, were you disappointed in it (it added no value)? This too was captured on a large wall chart. It was completely visible for everyone to see, including our guests.

What do we do with this information?

In the afternoon of the first day, we switched our facilitators and used new processes: a Kanban board of agenda items versus a list of agenda topics. The group of 25, along with our 12 guest observers, had a lot to absorb. Our first step was to quickly build a bridge of empathy about the morning participants and their work. To do this, we turned to Empathy Maps, an approach to learning we’d practiced with people from the Stanford d.school. We also followed guidance from the book Gamestorming. Teams of 4-6 people (including our guests) gathered at separate wall charts to brainstorm about the morning. What did we notice about the 60 participants? What had the 60 people from the various departments heard, said, seen, done, thought and felt during the morning session?  The readout, in particular from our guest observers, revealed a great deal about how people were engaged; what they were concerned about; what they valued; what gave them energy; how open were they, and, what they might have taken away from the meeting.

We also re-visited the morning group’s insights and risks as well as the voting on the proposed Mother Strategies looking at the bar charts and comments. This was revelatory. We discovered some strong opinions we didn’t expect. The main revelation? How do these five proposed Mother Strategies help the entire company focus for the year? How do they help the company determine what to stop doing, start doing, and keep doing? In sum, the group of 60 sought assurances and clarity about how to do their steering through the year.

Wrapping up Day 1 of Iteration 3

Our first day of Iteration 3 started to wrap up after open dialogue around the proposed Mother strategies. Each of the 25 participants self-selected which strategies invited their focus. These sub-groups provided more detail around the strategy, outlined initial metrics, and created a 4-minute”stump” speech using a Bert Decker grid for crystallizing their messaging. The results were both stunning and energizing. We were ready to bring our work into the morning session of day 2. We ended the day by holding a retrospective on the overall day and by asking our guest observers to give us their feedback through their own ORID exercise.

Ask a guest customer to tell you about how you are doing. You’ll truly love the experience. Once again, their attention to detail, their observation of trends and their recommendations (for themselves and for us) made us so grateful for their presence.

Dinner and drinks sealed the deal at the day. So, ending this Part 1 of my series on “Guess Who’s Coming to Planning,” I’ll play off of the movie “Guess Who’s Coming to Dinner” a bit more explicitly. We fed liberally off each other’s insights. We challenged one another. We didn’t hold back. And, we held close to our sense of being a growing, learning community.

Stay tuned for Part 3 of our 4 part series on Rally’s annual planning journey. In Part 3, we’ll finish day 2 of Iteration 3. Part 4 will complete our series by wrapping up with Iterations 4 and 5.


Jean Tabaka is a serial collaborator, a relentless facilitator, a well-intended blogger, an author and Agile Fellow at Rally Software Development. If you don’t see her in your town, you can follow Jean on Twitter at @jeantabaka

Categories: Agile

Scrum: The Future for Education?

Scrum Log Jeff Sutherland - Thu, 04/26/2012 - 19:56

When we first heard about teachers using Scrum in a classroom we had to know more and got in touch with those teachers through Ilja Heitlager at Schuberg Philis in the Netherlands. Here's what they sent in. It's translated into English from the original Dutch.


eduScrum in Dutch education

How it began …
Imagine: you are a chemistry teacher at a school for secondary education. Your students work in groups on complex assignments, but you are not completely satisfied about the results of that teamwork. And then your son-in-law becomes a Scrum Master and you hear his enthusiastic stories… That is how it began.

How it continued …
Willy Wijnands and Jan van Rossum, chemistry teachers at Ashram College (secondary education in Alphen aan den Rijn, the Netherlands) have been using an educational version of scrum since October 2011: eduScrum. They incorporate scrum into their lessons, to give students the opportunity to study more energetic and more effective. Using eduScrum also stimulates students to develop their strength as a team player.

Team work starts in their lessons with an introduction about confidence and an activity in which students talk about their personal capabilities and soft skills like punctuality, leadership capabilities, planning skills etc. After that, they form groups of four, set up to have additional capabilities. In this way, individual strengths in a team make individual weaknesses less relevant. Subsequently, they work in groups on the assignments of the context-rich chemistry module from a detailed sprint schedule.

Teacher: ‘I have indicated the number of time points per assignment (one point equals 10 minutes) and requested them to make an individual schedule. They have discussed those schedules and processed them into a group schedule. When I pointed out that I also wanted to do some whole-class teaching, they told me there was no time for it and that I should have announced it earlier. Wonderful, that much ownership. But they have to be in for it, because they have to learn to cope with unexpected events in their schedule.’


Group of four students, almost simultaneously: ‘This work is more pleasant in a group rather than individually. It is possible to ask each other questions and divide the tasks, which saves time. We have divided the experiments, because they are a good deal of work. But today we are going to work in groups of four during the entire lesson, because these assignments are very important and everyone should understand them. That is why we work together, it is something we have thought about during planning.’

Every group starts the lesson with a short scrum. This way they know what they have to do and where they stand to each other. A subsequent step is for them to learn to call each other to account, in case a group does not function optimally. The first step in doing this is a short but effective evaluation, executed by the groups themselves. Confidence in each other is the key theme in this evaluation.

Boy: ‘Our group consist of two boys and two girls. A group is useful when the group members co-operate. We’re fine in our group. Everyone takes his or her responsibility.’

Girl from the same group: ‘Everybody is contributing in our group. We have committed ourselves to do the work and we all are living up to it. We do our own tasks, and also work together. We do not study alone, if one of us does not understand, we explain to each other instead of asking the teacher. The information we have found we share with our group.’

From a Scrum perspective this might be trivial, but from a traditional educational perspective (focusing on the individual cognitive training) this is very special.

The plans for the future …
Willy Wijnands and Jan van Rossum are working with with Ellen Reehorst, an education designer and trainer, to further develop eduScrum and to hand it over to other teachers later. Use these addresses to find out more:


www.eduscrum.nl
info@eduscrum.nl
@eduscrum on twitter







Categories: Agile

2012 Scrum Alliance Strategic Plan

Scrum Alliance - Tue, 04/24/2012 - 20:53
Categories: Agile

How Scrum Is Changing the Global Delivery Model for Software Development

Scrum Alliance - Mon, 04/23/2012 - 22:48
We're all familiar with the Waterfall offshore paradigm of software development, in which clients and vendors engage in an asynchronous, sequential model for software development. The client spends money and time to develop a formal project charte...
Categories: Agile

Yes, We're Doing Scrum

Scrum Alliance - Mon, 04/23/2012 - 22:44
In July 2011, the Scrum Alliance website featured an article by Alan E. Cyment entitled Compasses, Trees and Pains. It posed the question, Am I doing Scrum or not? Interestingly, one reader responded, 'Yeah, we're doing Scrum, but we have thr...
Categories: Agile

An Argument for Comprehensive User Stories

Scrum Alliance - Mon, 04/23/2012 - 22:39
As Scrum practitioners know, a user story is a high-level requirement of a feature, provided from the perspective of a stakeholder who desires the new capability. These requirements enable the development and testing team to think about a solution...
Categories: Agile
Syndicate content