What is a Definition of DONE, and why do we need one?
Posted on: August 8th, 2016
The goal of the Definition of DONE agreement is many fold, and it exists not only to create a standard by which teams can operate so that they can feel confident that when someone says, “I’m DONE!” they know precisely what that means, but also to ensure that all involved stakeholders understand when, why, and how to engage with a given team, and what they can expect from their contributions.
SPRINT/ITERATION REVIEW
Posted on: July 8th, 2016
In order for the team to review the work done in the previous Sprint/Iteration, a Sprint/Iteration Review is held. Note that this is not the occasion for the team to present the work to the Product Owner.
This Review meeting should be scheduled for the first available time slot after the end of the previous Sprint/Iteration and last 30 minutes for a single team, or up to 30 minutes per team for multiple teams in a single program. It is common for teams to schedule the first 30 minutes of their Sprint Planning meeting to review the previous Sprint.
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.
