Estimate the agile project's budget using story points

The budget of the project calculated mostly based on the effort. In agile projects the budget can be calculated based on story point also. The project manger needs to have clear input on the velocity of the team to calculate the budget.

Project Budget = Cost per Story Point * Total Story Points

Cost per story point = Cost of resources based on the effort spent / Story points per week

Assume you have team size of 8 with the rate of 80$ per hour.
The total working hours spent by person per week is 40 hours.
Total cost per week = 8 (team size) * 80 (rate in $) * 40 (hours/week) = 25,600$
Assume based on the velocity, you team able to complete 16 user stories.
Cost per story point = 25,600 (Cost of resources based on the effort spent) / 16 (Story points per week)
                                      =  1,600 $
Assume you have 500 story points planned for the project.

Project Budget = 1,600 * 500 = 8,00,000 $

Kanban Board for Agile Projects

In agile projects it’s common practice to visualize and project status in white board of the project war room.
The lean management in the production industry also uses this kind of practice.
“Kanban” in Japanese means, loosely translated card or sign. The kanban boards used to view the three point’s time task and team so that the whole team understands the current status of the project and work n an autonomous, motivated and collaborative manner.

Agile Risk Management

 The agile risk management and the process is the similar to the traditional risk management. (Refer risk management). The process integrates into the life cycle and the frequency of running varies considerably in the agile.

Agile Scrum check list

The idea of this article is to define the set of practices and process for the agile development project based on my experience.
I believe the good practices and checklist are essential for the agile project to measure the performance of the project.
The project teams are starting with agile adoptions and often struggle to find where they are standing. The check list helps to agile team to figure out the painful area and overcome from that.

Agile Iteration Planning

Agile iteration:

Agile iteration is a consistent time-box in which a delivery team plans, delivers and receives feedback on a product increment.

Daily Agile Scrum stand-up meeting guidelines

Daily Agile Scrum stand-up meeting guidelines:

Followers of the Scrum method of project management will typically start their day with a "stand-up meeting". In short, this is a quick daily meeting (15 minutes or less) where the participants share the answers to the three questions with each other:

What do we talk about during the daily stand-up?
Yesterday Today Obstacles 

What is Agile Scrum?

• What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Agile Scrum Questions and Answers

Question: What is a Product or Project Backlog?
Answer: A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Question: Who provides the requirements in Product or Project Backlog?
Answer: It is typically the role of a product owner or a customer to provide the requirements. However, sometimes analysts from the development team can work with product owner or customer to define the requirements. The idea is for the product owner or customer to work with the team to discuss the requirements during the sprint planning meeting.

Question: How are the requirements written?
Answer: There is no standard way to write the requirements. One team can simply write “users sign in” and another could write “users should be able to sign in with their email address and password”.

Question: Is additional information captured in the requirements?
Answer: Yes and no. It depends on project to project and requirement to requirement. Something like Forgot Password might not need further information but something like User Registration might have various notes on each field like date of birth (should be 13 or more) and password (strength).

Question: Do we require “acceptance tests” for the requirements?
Answer: Yes, highly recommended. However, having acceptance tests for all requirements would be too time consuming. Also, the team and product owner or customer should discuss the acceptance tests for each requirement in detail during the sprint planning meeting. It is useful to remember that Agile is collaborative and both the customer or product owner and team should discuss and agree on “definition of done” before the start of a sprint.

Question: Do we need details on everything for each requirement on the backlog?
Answer: This is not really required, although nothing stops you from going this route. However, the closer the requirements are placed to the current sprint, the better they should be defined.

Question: Do we need to estimate each requirement in the backlog?
Answer: Yes, it is recommended that each requirement be estimated. The requirements far from the current sprint can only be coarse grained and hence roughly estimated. However, this gives product owner or customer a rough idea of the project size and number of sprints required to complete a project. The final number of sprints could be more or less, but at each stage the visibility of progress would be self evident.

Question: How is the estimate done - in days or in hours?
Answer: You could use either, although relative estimation would work better. The team and product owner get together at sprint planning meeting. They pick up the simplest requirement from the list and arbitrarily assign a number to the same [say 1 or 1 requirement point or better still 1 coffee cup]. All other requirements are estimated in similar units [requirement points or coffee cups]. At the end you total up the points. At first the team could take a guess at the amount of points it could complete in a sprint. After a few sprints, they would have visibility of how many points they should ideally take. This estimation technique works well to give you rough idea of work that can be picked up. Its not supposed to be used for precise calculations or a point in horizon rather just aim for a region in horizon.

Question: How do we estimate - based on size or complexity?
Answer: The short answer to that is both! Entering 1000 records in database might not be complex, but time consuming and on the other hand investigate SOA performance issues in reports in a clustered environment may be complex and hence, difficult to even give a precise estimate on. And in some cases, you might want to factor in both. Hence, you estimate both from difficulty level as well as effort required.

Question: How is the backlog prioritized?
Answer: It is the responsibility of product owner or customer to prioritize the backlog. The team can provide assistance in the same though. The backlog is prioritized by factoring in risk factor of not doing the requirement right now and opportunity by delaying the requirement decision later. In simpler terms, risk factor, dependencies and business value would help the team decide the priority.

Question: Does the backlog provide any tracking?
Answer: Yes, you can make a simple tracking of completed/ pending items. You can also track number of requirement points completed in a sprint and based on average requirement points completed in a sprint and total requirement points pending, you can get an idea of the projected completion date. The average requirement points completed in a sprint is also called velocity.

Question: Is there a low level tracking involved?
Answer: Yes, you can divide each requirement into tasks. Each task can be estimated in number of hours it would take to complete. This is typically done only for a given sprint and is called a sprint backlog and is maintained separately from product or project backlog.

Question: Is the product or project backlog only made once - at the start of a project?
Answer: No! There are only two rules. First,the product or project backlog should be revised and continuously updated based on emergent scenarios and situation. Second, the backlog for the sprint currently in progress can’t be changed. The backlog for upcoming sprints can be changed almost completely. In a fixed price scenario, this might mean you need to swap new functionality with existing functionality.

Waterfall Model Vs Agile Scrum

Traditional software development methodologies such as Waterfall Model has been quite famous and been used by many software development teams and enterprises across the world. A typical Waterfall Model is as shown below;

·         It follows a very logical path, first do a thorough study on the customer requirements and then freeze the requirements.

·         Frozen Requirement Spec is then analyzed by the design team and a complete design document gets written, documented and reviewed by every stake holders.

·         Design document gets translated in to the product and gets tested/verified by a group of verification engineers/customers etc.

·         Once the product is released in to the market, enters in to maintenance mode.

Though Waterfall Model is logical, there is a biggest flaw in it. Every stage waterfalls in to the remaining and the main threat to the project that follows Waterfall Model is the first stage, that is “Requirements” stage. In real life, requirements never get frozen; for various reasons;

·         Customers do not know exactly what they want; they change their mind often

·         Market is volatile – priorities change overnight

·         Competition from rival companies

·         Humans can not predict a long term product development cycle.

·         Release happens at the end – generally months after customer provides requirements. Often, they don’t get what they wanted. Now, they can not change requirements as it is too late.

These are the major factors make Waterfall Model to fail often since project involves Humans. This is the primary reason why Scrum gained its popularity.

Scrum is based on;

·         Team takes a shorter step in a fixed iterative manner

·         Team along with the Stakeholders/Customers inspects what was developed and adapts changes as needed as per customer requirements. Customer comes to know in a shorter time about the product they are waiting for. They can provide comments etc

·         Scrum encourages changes – team wants customer to have the best possible product that improves/enhances lives of customers. Where as Waterfall Model discourages changes at the later stages.

·         Scrum understands that good ideas can come at any time during the project. Waterfall model does not.