Scrum planning meeting: because everything is created twice

"Good plans shape good decisions. That's why good planning helps to make elusive dreams come true."- Lester Robert Bittel

    With Scrum and at the beginning of each sprint, the team, scrum Master , product owner and may be some of the stakeholders (expert ,clients representative ..) are invited to attend a time boxed meeting where we are going to discuss and negotiate the scope of the current sprint .The goal is to create a blueprint and develop construction plans before any code is produced : the first creation. Indeed the goal of the scrum planning meeting is to try to get a very clear sense of what the team is going to commit to during the sprint ,if we want a drag and drop or a simple table view ,if we want a synchronous or asynchronous functions calls … .We work with our imagination and visualization to create and get a very clear image of what we want to accomplish at the end of the sprint ,thus to share a transversal vision among all the team before the second creation or the physical creation where the code get typed take place, in order to prevent expensive changes that may increase the cost of failure over the implementation process.

   During this meeting the product owner describes the highest priority stories to the team. Some questions and negotiation may follow to limit the scope of what is going to be taken to the sprint backlog, the team subsequently discusses the committed to stories and how the implementation will be built (conception, just-in-time design...).The presence of the product owner is important at this part even if he is not directly involved, since further questions and clarification asked by the team may help them taking better technical decision and making better decomposition of the stories into tasks. The tasks are then estimated and each team member chooses what he will be committed to .The velocity input from past stories allows the team to make a realistic commitment to the scope of the work being defined to prevent demotivation coming from the “unrealistic initial estimation” excuse.

   At the end, an explicit agreement from the team on the sprint backlog is made, and the product backlog, release and sprint burndown charts are updated.

How to make an agile software user card ?

Agile User Stories are a simple way of capturing user just-in-time requirements throughout a project. They are feature oriented and help to emphasis and cover the why, who, and what on each backlog feature.

So, what makes a good User Story?

The INVEST acronym can help to enlighten this:

I – Independent : Stories are easiest to work with if they are independent
N – Negotiable : they are not contract
V - Valuable : each card might add business value to the customer
E - Estimable: not a precise estimation, the time box can be negotiated.
S - Small : at most a few person-weeks of work
T - Testable : writing the tests early helps to know whether the goal of the User Story is met or not

What should a user story card contain?

There is no fixed template on what a user card should contain, it always depends on the project’s need, more centered, it depends on the need of each product backlog feature, the aim is always to bring everyone to a common understanding of what may be the need and the result.
A common and general template may contain the key points below:

Stakeholder’s description and estimated time .

DBA	Developer	Architect	Estimated time
A	B	C	hours or unite

Story card name or id :
Useful when managing requirements.

Story card goal:
As a User or role I want Business Functionality so that Business Justification

Business scope:
Description of the business added value. (exp: Development of this report will help administrator to send punctual status to investigator when demanded).

Use case scenario :
Not always needed, but helps better understanding.
Exp :
1. Recruiter submits credit card number, date, and authentication information.
2. System validates credit card.
3. System charges credit card full amount.
4. Job posting is made viewable to job seekers.
5. Recruiter is given a unique confirmation number

User Interface with inputs validation.

Security:
who should have access to what.
Exp:
Role ADMIN:Create/ Update /Submit
Role MANAGER: Update /Submit.

Business rules and policies.

Acceptance Criteria:
What makes the story card 100% done.
Exp :
1.Release Specification.
2.Stability Specifications.
3.Process Dependent Specifications.
4.Functionality that the system will perform
5.Interface look and feel
6.Necessary documentation

Comments:
Impediment, impact, estimation… whatever helps historical learning.

The goal is always to better serve the client by keeping the focus on the goal of the product rather than the list of its attributes.

How to start implementing agile practices in your company ?

Implementing an agile method in your company may requires continuous and progressive changes to raise stakeholders commitment and culture to handle those new packaged practices ,thus you may start by implementing actions that have an almost direct impact on quality assurance issues and development life cycle to make your team more productive and rigorous through the release process. Here are some of the points you may start with, to help you going through:

Just in time and lightweight requirements:
Keep the requirement level at the minimum required to start the development process.

Automated repeatable unit tests :
Test must be integrated throughout the lifecycle, not at the end .Test scenarios should be written before the development starts (knowing that you would write them anyway!).

Software release must rely on customer feedback :
Don’t waste your time developing unusable functionalities that wouldn’t add any business value to your software; focus on getting the most important features and items first to the market. Make them prioritized to get the better of agility and flexibility.

Stick to a regular software release cycle:
Fixed release cycle (iteration, sprint) is vital, it creates routine (stakeholders, departments, team members) and routine increases productivity. At the end of each release, all features must be completely done and functional, this ensures a clear and complete vision toward the software development progress, reduced risk and higher value.

Get the best of your stakeholders:
By making them working toward a shared goal.

Remember, the success of your project is all about making your stakeholders happy :).