Integral Agile Journal

THE SPRINT DEMO

Posted on: June 5th, 2016

At the end of each Sprint/Iteration, a Demo meeting is held where the Team shows what they accomplished during the past 2 weeks. Given that Agile is an empirical process, and the goal of every Sprint is to product Potentially Shippable Software, only work that meets the Definition of DONE is demonstrated at the end of the Sprint. The Demo usually consists of the development team, the Scrum Master, the Product Owner, but is essentially an open meeting, and all stakeholders, leaders, and interested parties are invited and encouraged to join to observe the team’s progress.

SPRINT/ITERATION PLANNING

Posted on: May 7th, 2016

The purpose of Sprint/Iteration Planning is for a team to identify and commit to the total amount of work they think they can to accomplish within a 2 week period. In order to have a successful Sprint Planning meeting, there needs to be an organized, prioritized backlog with a sufficient amount of stories in a READY state for the team to pick up and complete within the iteration. A typical Sprint Planning meeting proceeds as follows.

BEST PRACTICES FOR DEFINING USER STORIES

Posted on: April 5th, 2016

Many new agile teams attempt to create stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy Small requirement, but it fails at Independent and Valuable (as part of the Bill Wake’s INVEST model).

Typically, large User Stories can be split using several of patterns. Here are two general rules of thumb in determining the right split to make:

USER STORIES

Posted on: March 5th, 2016

These next couple of posts will take things down to the most basic of Agile requirements: the User Story. A User Story is a tool used in the Agile development methodology to capture a description of functionality from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a software requirement.

User Story is a brief statement of intent that describes something the system needs to do for the user. We write them to relate business objectives and value:

Empirical Management

Posted on: February 14th, 2016

Aliases: Adaptive Management …

Your company has been using a traditional approach to management of engineering projects. Now, senior management wants to change how they manage and execute projects so that they can better deliver software – faster and cheaper.

???

Teaching to the Test

Posted on: December 14th, 2015

by Bill Rinko-Gay

This blog is a follow-on to the post entitled “Open Book Testing.” If you haven’t already, you may want to read that first.

Once you have reviewed all your test stories it’s time to prepare to execute them. A well planned test execution, in conjunction with a well planned code implementation, helps to actually build quality in as well as verify the quality of the completed software.

Open Book Testing

Posted on: November 11th, 2015

by Bill Rinko-Gay

There are two components of quality software: building the right thing and building the thing right. One of the most difficult things to get right is knowing what the right thing is. In non-Agile methods this puts the focus on defining complete and detailed requirements. Experience shows that it is very difficult, if not impossible, to specify exactly what you want when you haven’t seen or worked with it yet.

Agile Quality Assurance

Posted on: September 30th, 2015

by Bill Rinko-Gay

Software Development is not Manufacturing

Posted on: August 5th, 2015

Software Development is Not Manufacturing

… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.

???

A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.

Team Metrics

Posted on: June 30th, 2015

Team Metrics

  • How fast are we going?
  • What’s our biggest obstacle to velocity?
  • Does we have enough requirements defined?
  • Are we building the most valuable things we can?
  • Is there something we’re deferring that should be worked on now?
  • Are we getting things all the way done?
  • What would we have if we had to ship tomorrow?

Pages