Delivering Accepted product increment to the customer

The Release phase emphasizes delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project. Accepted Deliverables are delivered or transitioned to the relevant stakeholders. In the Ship deliverables process of Scrum, a formal Working Deliverables Agreement documents the successful completion of the Sprint.

The inputs, tools, and outcomes of this process are as follows:
INPUTS
1.            Product Owner*
2.            Stakeholder(s)*
3.            Accepted Deliverables*
4.            Release Planning Schedule*
5.            Scrum Master
6.            Scrum Team
7.            User Story Acceptance Criteria
8.            Piloting Plan
9.            Scrum Guidance Body Recommendations

TOOLS
1.            Organizational Deployment Methods*
2.            Communication Plan

OUTPUTS
1.            Working Deliverables Agreement*
2.            Working Deliverables
3.            Product Releases
(*) indicates the mandatory points.
The working deliverable is the final shippable deliverable for which the project was sanctioned. As new product increments are created, they are continually integrated into prior increments, so there is a potentially shippable product available at all times throughout the project.
The Product Releases should include the following:
•             Release Content—this consists of essential information about the deliverables that can assist the Customer Support Team.
•             Release Notes—Release Notes should include external or market facing shipping criteria for the product to be delivered.

 To know more click on: http://www.scrumstudy.com/blog/

Agile Project Feasibility – Chapter 1

Project backlogs are full of great ideas. In some cases, we get so excited about a great idea that we disregard all the challenges and jump right in to start development. Sometimes we succeed, and sometimes we have to abort. Many companies struggle when trying to validate a project’s value. Some companies initialize a project without knowing if it’s viable; other companies scrutinize the value of a project for months before making a decision. There are issues with both approaches.

 If you perform minimal validation, you’ll frequently deliver projects that provide marginal value. You may also find that you’re aborting on projects because you overlooked major risks at the outset. In both instances, you waste company time and resources and potentially lose the opportunity to deliver valuable projects. Companies that perform too much validation have a different set of issues. These companies create so many hurdles and gateways that a considerable expense is associated with project justification. They also minimize their ability to achieve benefits from projects that need to deliver value early: time that could be spent performing the project is frequently lost to the justification cycle.

How do you know when you’ve done enough research? How can you tell if a project is feasible without overkill? We suggest using the feasibility process outlined in this chapter.

This process works for two reasons:

• The feasibility effort is time-boxed.
• The team is empowered to question the viability of the project after the Feasibility phase.

Time-boxing the effort prevents a runaway train. A time limit adds urgency to the effort and prevents waste. A good rule of thumb is to keep the time within 2 to 5 days.

Some employees won’t be happy with this time limit: they will say that each project is different and that larger projects require more time for feasibility work. They will also say that setting a fixed time for an activity is anti-agile. We agree with all these points. This is where our second point comes into play: the team can cancel the project at any time.

During the Feasibility phase, you’ll make a quick call about whether to go forward. This will prevent you from missing an opportunity due to over-analysis. You’ll use the Planning phase to learn more about each individual feature; and as you do this, you’ll continue to consider project feasibility. You can still cancel the project if you encounter risks and issues during the Planning phase.

To know more: http://www.scrumstudy.com/blog/agile-project-feasibility/