Showing posts with label Product Backlog. Show all posts
Showing posts with label Product Backlog. Show all posts

Wednesday, November 29, 2006

Free Scrum tool - Great

12 comments

This is really a great tool for Scrum. I just went through the features and its quite good. Thanks to my colleague who sent me this link.

http://danube.com/sw_flash/SWB_Demo.html

But ….remember. Tools will not manage your projects.. Its you who should manage the project.. These are just “ Tools” and that’s why they are called “ Tools” when all the methodologies and tools are failed.. its you who make the project a success…

I have come across with many project managers who just spend their whole time to manage the tool instead of the project. Having the best hammer in the world doesn’t make you a good carpenter or having the best cricket bat in the world doesn’t make you a good cricketer. Coz they are tools to help you to perform your tasks. That’s you who make it happen…

Friday, August 25, 2006

Easy Scrum – 3 Don’t let this happen

2 comments

Ok this is another experience I had with scrum teams; One day I noticed that our daily scrum meetings were going on for hours.

What we have to keep in mind is that, the Daily Scrum is not used as a problem-solving or issue resolution meeting.(this is the exact mistake they did) Otherwise what happens is that daily scrum takes too long and due to the issues raised by few people, the whole team keeps on arguing and going on in different directions. Actually those issues can be taken care of, after the daily scrum meeting with affected team members.

During the Daily Scrum meeting, each team member is asked to answer the following questions;

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?

So the sprint backlog should be updated accordingly. and if there are any impediments, they should be listed . After the scrum meeting, you can take care of the issues found out at the meeting or any other adhoc issues.. Other wise You will start the scrum meeting at 9AM and go till 5Pm when there is a critical issue with your program specs or class diagrams..

Thursday, August 10, 2006

Easy Scrum – 2

0 comments

First I thought of writing details of each step of Scrum. with that idea in my mind, I posted “Easy Scrum – 1”. But Yesterday I did sort of a case study with one of my teams to practice Scrum. So I thought its worth to write about it and it covers the whole cycle.


Ok here it goes…

I got the team together, none of them have practiced Scrum before., I did some initial presentation of Scrum to get some idea and then gave them the case study.


The case study was a Project to make a “Vesak Lantern”. ( I have very few Sri Lankan readers reading my blog, but so many overseas readers. So its worth to explain what a Vesak Lantern is . Vesak Lantern is a Lantern we Buddhists make for the Vesak day ( Lord Buddha’s Birthday )celebration ). So all my team members have made at least one vesak lantern and they have the “Industry Knowledge” . So it was easy. I acted as the customer to change the decoration requirements of the Vesak Lantern the way I want ( It was annoying J )


Project Constraints:

Vesak day is May 21st. It’s a Project Constraint.


Product Backlog :


We have to light the lantern on the Vesak day night.

So the team got busy. First I selected a Scrum Master. And I asked them to create the product backlog.. That was interesting., Planning, Designing, Making the Skeleton, Purchasing Materials, pasting papers, Setting Light Bulbs so many things in the list., .. What happens if there is a power failure on Vesak Day.? ( Which is very common in Sri Lanka). They had the risk plan too.. the mitigation was to light a candle inside the lantern instead of a light bulb.

The design we wanted was a aero plane shape of a Lantern. But I kept on asking changes to that.


Once the Product backlog is made, it was estimated with required man power cost and the material cost. But the team had to revise it many times and recalculate it as the requirements kept on elaborating


Then the priorities were decided by the scrum master and the team., of course you cannot paste papers without making the skeleton. They prioritized the tasks accordingly


Sprint

They defined sprints, durations for Sprints were vary. They selected the Items based on the resource availability and Priority for the first sprint. Sprint backlog was created.

Daily Meetings

As a good Scrum team, my fine team simulated the daily standup meetings.. But they wanted to sit and chat instead of standing, Never mind.. This is easy scrum.. so I told them that its ok.. Every day at 9AM the team meet to discuss the daily plan and 5PM to review the daily achievements.. It went on for the whole sprint..

How about the people who try to skip meetings? Do we have a penalty.. Yeah .. Rs. 100 ($1 ) should be collected from absentees and use it for team outings after some time…If I have a good team.. I will not have money in the till :-)


This is a very productive thing.. We do not slip daily targets and we do not postpone work until the last day and then struggle with it or just do something about it.. I know the team will find this bit hard at first. But they all will appreciate it after some time..


Burn down Charts

Scrum master created the Product Burn Down chart based on the items taken off for the sprint. We didn’t create any Sprint burn down charts as our duration for the sprint is very short.


Impediment List

One of the objectives of daily standup meetings is that to foresee the barriers for the team to achieve their daily workload and eliminate those barriers. So we are not waiting till the last minute project meetings in order to find why we have not achieved such tasks and to realize its too late.. They found that the guy who had to purchase material doesn’t have a vehicle to go to the stores. So they have eliminated the problem by hiring a vehicle for that.

Product backlog Delta Report

Scrum master kept on updating the product backlog Delta report. I found the status of items as follows.

Not Done (initial state)

In Progress

Done

Deferred

Deleted

Lessons Learned

We completed the lessons learned after every Sprint. So we could more or less eliminate the over estimating issues in latter sprints.


Project Management office?

PMO wanted few standard reports . So we completed the Milestones report and weekly Project update report based on Product backlog.

Over all we could get the team buy – in for the method by doing a case study with lot of fun. I think if you need to introduce such methodology to your teams, this may be a good start.

Conclusion

+ points

Scrum is really a good way to manage projects which are quite uncertain

Every team member feel that they have a major Stake in the Project.

Team members have a very good understanding of the workload and the challenges they should face in the project as a team.

Team members don’t feel that work is assigned to them., they feel that they have volunteered to do tasks as they want to be the winning team.

Over all very good Project Control

With this method.. you are never too late.. Because you don’t wait till you are too late.

Its no more covering backside for anybody..

Difficulties I see

Sometimes its hard to practice this with people who are not in same caliber with other team members.

Taking leave affect the sprint backlog

Difficulties of committing to the final deadline due to multiple iterations

Difficulties to negotiate with project budgets time to time

Thursday, August 03, 2006

Easy Scrum - 1

6 comments

We have a Project to develop a common product for Retail Distribution. I thought of using an Agile method in order to manage this project due to the nature of this project. This has more chances of changing the scope and the project seems very uncertain. So We selected Scrum.

But we have many challenges..

We don’t have a Scrum Master. We have only a Project Manager. We don’t have a Customer working with us., But we have a Domain Expert within the team who will act as our customer. We don’t have Microsoft Team Systems. But we have Microsoft XL. We have a Project Office which needs some sort of generalized templates of all the projects.

How do we go with it.. ?

First I wanted the team to be familiarize with Scrum. The Problem is training.. We don’t have such training and workshops available here and no project budget to send them overseas. So the next option was Web and Online mentors.( Which is the only option we had)

My main concern here is the caliber of people we have for this Project., To practice Scrum Its really required to have team members who contribute to the product., And not the team members who just code the given spec and think of themselves as furniture of the company.


Step 1 - Create Product Backlog


First we got to create a Product Backlog.. How do we do that? Its very Simple.

You got to create a list of all the product functionalities ( You can simply use a XL sheet or MS VS Team Systems). You may have got so many documentation at this time. Go through it clearly, understand the required functionalities, understand everything what you have to do with the project, List them. Then prioritize them in order to see which ones to be completed first, depending on their dependencies, impotencies and effort requirements.

Then the question comes.. Who can add items to Product Backlog.?? Do I have to secure this sheet with a Password? No ..In our case we asked everybody to add items., PM, Tech Lead,Project Owner, Team, Domain Experts and so on. Then we prioritized them based on the required functionality of the product in order to do release 1 of the product.

WBS vs Product Backlog

Remember your good old WBS? (Work Breakdown Structure is the deliverable based grouping mechanism inProject Management ).. You can see the Product Backlog as something similar to that. Both can be used by the PMO to understand the amount of work to be carried out in the organization’s projects. The Difference is that WBS is a Deliverable based Grouping and it doesn’t reflect prioritization of your task or estimations. Its more or less defined, and its created by the Project Manager. But Product backlog has almost everything you got to do with the project. It shows which tasks to be done first., and the value and importance of them. Any stakeholder can add items to the backlog. New Items will be added over a time period.

WBS helps a PM to plan the required work Packages and estimate them., Product Backlog helps the PM and team to plan items for a Sprint. ( Short time Period) and estimate the work to be carried out.

Once the Complexity / Value and risk is identified for each item, You got to estimate your Product Backlog. This can happen in 2 instances

  1. A new Item is added to the Product Backlog
  2. Existing backlog item is substantively changed.


How do you estimate the Product Back log? Are you going to categorize items by Size and put a weight on each category? Or is it by any other costing methodology?

This is very useful for the Project manager to evaluate the effort involved in a release and this allows the team to select the backlog items for the coming sprint.

Be a PMP
 

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com