User stories - Do they need a format ?

Every person whom I meet teaches me how much I don’t know about some subject. Either its about the world, history, culture, religion, different industries… whatever it is…This happens to me all the time when travelling. I have some luck to have good company most the time while travelling or in transit. Those strangers ended up being my “friends” frequently.

This time when I was travelling from Frankfurt to Doha, Some stranger fell in to conversation with me after seen my notebook bag ( I think I have mentioned about this notebook bag before in this blog J ) He assumed that I work for an IT company and he is an Agile management consultant based in Denmark and travelling to Doha for some assignment. You can imagine now.. a conversation in a long flight extended by 1 hour delay J

It was very interesting to know about various experiences we both had with Scrum and he was quite used to many other agile methods which I have never been exposed to before. However we both agreed that Scrum is the most popular Agile (According to him.. “The well marketed and money making Agile”) right now.

Talking about various experiences I asked his experience about user stories. This was some challenging area in Scrum projects. Getting the user stories right…

I always believed its better to have the standard for user stories “ As a “, “I need to “ “So that I can”.. In this way the requirements become much clearer to everyone and we may not miss the users what their expectations etc.. But he disagreed. I was surprised, but he had a valid argument on this. Example: As a Job applicant I want to post my CV to the job portal so that the prospective employers can view my CV in PDF format”

His argument was that its always difficult to stick with real users in user stories. As an example; you want to have date widgets in an application, so that do you write “as a designer I want to use the list of widgets so that “…….. ??? Where is the real user in this user story? ? I couldn’t agree less. Because I just completed a project initiation where there were many many user stories which I couldn’t think of mapping to my standard template originally but I had to do it by force with tweaking them by using developers, designers , architects as types of users which may not be the best case.. He also had the same experience .. One of his initial product backlogs 80% of the time it has been “ As a product owner “ which doesn’t make any sense…J

But then.. Million dollar question.. Why Mike Cohn standardized that user stories in a standard way? Didn’t he see this problem? I don’t think so .. Need much more thinking and reading on this.. may be some times not using standards would be better than using standards if they are not meaningful.. I will definitely do a follow-up post on this..

Anyway bottom line out of scrum is that speak to anyone who try to make a conversation with you…never know what they will come up with J

Yeah Im not a person who can live with open ended questions.. So Im chasing answers:

28th June..

Follow up today : I purchased the book from Amazon "User Stories Applied: For Agile Software Development " by Mike Cohn

29th June

I found this article :

Missing Dimention of user stories : Interesting thoughts:

Newbie to Agile.. Some random things based on my experience so far..

1. Scrum is only one of the Agile methods. There are many. But at the moment Scrum is the most popular due to its simplicity and not forgetting the scrum alliance marketing effort too.. ;-)

2. I had a situation where the product owner had an idea.. Agile is no documentation.. period!.. This is not right! If you look at what Agile Manifesto says “they prefer working software over comprehensive documentation and not over any documentation. The point is that more effort should be for making software and not for making documentation. But we always need simple good documentation in software. Which is a known factor.

3. Can the none technical Project Manager becomes the Scrum master? My answer is YES. But still if you have a choice, go for the technical guy. Because in Scrum the “Management “ is very less. All what you have is team work and coordination and resolving impediments. When the Scrum master is a techie he will be very efficient in conducting the scrum stand up meetings in the morning and resolving technical impediments for the team members to sign in for respective tasks. But still if the scrum master is none technical.. its team work.. get the techies to help you in all the aspects…

4. Sometimes I see many think that you don’t have to commit on a release date in scrum. No.. in real world it doesn’t happen like that. There is always a tentative date.. But what happens is that based on the changes to the PB, your time expansions or reductions become much more visible to the product owner. Therefore there will be lesser problems to convince on expanded time lines

5. How do we do the DB design , Architecture UI themes etc? Part by part for each delivery? No what best I have experienced is that have a pre sprint on those high level tasks which you need to perform for the whole project at once. But minimize them and have only the vital ones.

6. How do we use Scrum for research projects? – I think it’s the ideal. Very uncertain type of work.. Scrum works fine !

7. Do we still have to do reporting to the management? YeAAS – Recently I read an Article by Mike and he suggest to continue the same type of reporting as much as possible till Agile thinking mature in the organization.

8. Is Gantt charts needed.. For me the answer is “NO” but again Ive seen many agile gurus have mentioned that .. use it as a communication tool if really needed by someone.. But personally I don’t like Gantt charts..

9. Is MS Project needed for Scrum : NOOOOO

10. How about the WBS ? I say keep it as the component diagram for the project.. this has many advantages over disadvantages.

11. How long a waterfall team will take to convert to a scrum team: My experience is 2 days most the time.

12. Is planning Poker a must? Nope Nope.. But when you don’t play cards some team members start to play ;-) specially in SL context not all team members talk. Planning poker help to define your ideas and stand by it ., then there will be so much valuable points coming from the team about a particular user story. I find it helpful.

13. Do you only assign the weight to a task in the sprint? No for me number of hours at this point is also important.. the secret is not more than 16 hours per task.

14. Can you compare velocity of multiple teams to identify team performance? : NO because there is no base for that. Different team may assess weight to similar tasks differently.

15. How do you practice scrum in outsourced Projects? A million dollar question. But still possible.. there are many tools which may help with customer communication when it comes to product backlog and sprint backlog. The secret is ask the product backlog in advance.. so you can be well prepared..

16. Will the PO always write user stories?.. Hmm…….. :)Somebody has to do all the work sometimes…

17. One tip I would give is that when playing planning poker.. get the moderator to write notes about the requirements elaborated by the PO and the team. Recording the conversation is really a good idea.

Cone of Uncertainty

Uncertainty of project estimates (Specially the software projects) is the biggest problem we face when planning a project ahead. I’ve never made a perfect plan for a project (The preliminary plan to be valid till the project is completed and to complete the project successfully with the same exact number of hours I planned initially?? No I have never been lucky).. So how do we deal with this uncertainty of projects when planning? Yeah I hear you .. Agile .. Scrum.. NO in this post I’m not talking about that.. Im just talking about our normal pre planned projects.
“Cone of uncertainty” (research done by NASA) reflects the uncertainty at different points of sequential development of a project. It shows that
In feasibility study stage schedule estimate can be different in a range of 60% - 160%
After the requirement specifications - + or – 15%
Likewise when the project progress each stage of the project reduces the uncertainly of the estimate. However uncertainty of estimate becomes 0 when the software is accepted.
Ok this is a long discussed theory.. then what does PMI say about the project uncertainty ? I wanted to refresh my memory J
PMI also believe in progressive accuracy of estimation. PMI defines some asymmetric way of viewing the uncertainty of estimates.
Initial order of magnitude estimate can have a difference from +75% to -25%
Budgetary estimate can have a difference from +25% to -10%
Final definitive estimate reduce the difference up to +10% to -5% Most the time at the level of the budgetary estimate , we sign up the contract with the customer. So we have somewhat risk in the estimations to take in to consideration when preparation of the estimates.
Twice I worked with some pretty large projects where we had to agree on penalties for each day of the schedule over run if occurred in the project.. Both times I could manage it within the agreed schedule.. (So didn’t pay any penalty to the customer) But I didn’t complete the project with expected profit to the last cent. Because I had to do certain resource utilization variance to deliver a project which was confirmed based on the budgetary estimate.
But now that I need to think beyond what I see I just like to have some feedback from other readers about this situation.. One solution which we can do is to apply risk factor to the budgetary estimate and have the luxury of that provision. The other solution is revising the estimate in selected milestones. I have done that many times.. but this needs establishing trust , loads of negotiations and convincing with the customer and other stakeholders as most of the stakeholders don’t care about cone of uncertainly..:-) The Million dollar question is that how do you handle this situation in traditional project management methods without hurting your project bottom line ?

All work and no play ???

few readers recently asked me the question.. "Why do you make such noise about planning Poker..We have been doing this all the time even long before SCRUM became popular.. we have been discussing with all our teams when estimating Instead having poker cards and playing poker.. …”.. Yeah.. Ok I will answer..
1. When you discuss with the teams about estimation at the meeting without poker.. Fine.. But will everybody’s opinions be highlighted? Or is it still the voice of few people in the team? Think about the last discussion you had with your team.
2. Sometimes work is uninteresting.. Have you heard that before? (Specially the estimation Yaiiik.. to me that’s not a very interesting part of PM J ) But that depends on exactly how you engage with those activities..Playing poker can help in this a lot. It’s fun!
3. When you just discuss with the team about the estimation for a functional point or for the user story, they just answer.. But there is no way that you can visualize their thinking with some relative weight at the time of the discussion.. This is where your Poker card set helps. And the each individual try to reason out their decision with lots of valuable points as they are exposed with the card they play every time.
4. Further this can eliminate chaos which happens in most the planning meetings. Can think lot more.. But these are the main reasons why I encourage my teams to play poker at the product backlog and the sprint backlog planning meetings.
I read an interesting paper by Jason Yip today about Project release planning with Poker..But this is not with our card set.. This is with real tokens.. J Interesting … you can find the paper here…
http://hillside.net/plop/2007/papers/PLoP2007_Yip.pdf

Ok.. its kinda sad thing.. This time Im very unlucky with Amazon.. I ordered the book., Agile Estimating and Planning (Robert C. Martin Series)
by Mike Cohn. A book which I really wanted to have with me after going through many of his blog posts and the book reviews..
But it was never delivered to me. So I made the complain to Amazon.. they sent it again.. Didn’t receive yet.. its over one month now :( ....disappointing … Not a problem with Amazon.. but Im sure its something to do with our internal postal process.. As I checked with one of my colleagues and he said that they dont deliver the books to our doorsteps now . we have to go to a central post office and collect it .. ...:-( whyyyyy ????????????..............But I didnt get a letter like that either... So I dont know......

Do I raise the issue again.. hmmmm..

SCRUM ... Issues.. ?

I had an interesting SCRUM discussion lately.. With one of the visitors who came to office. We had some point to discuss the PM frameworks and then we were discussing SCRUM in detail. He came up with some interesting point …
Will SCRUM kill the creativity of the development teams… ?
Developers produce piece of code.. in SCRUM we go up to the atomic level planning..so this specific task can be done in X number of hours.. true.. But if there is no such time boxes can they be much more creative…….I mean if we don’t look at the daily velocity of the graph… what would it be?
Hmmmmm… Hmmmm….. Hm…. I was stuck…. Yeah there is a point..
While going home I was thinking about this...
I think its like this .. In SCRUM we discuss what the customer wants in detail and in more detail at the Product backlog meeting as well as in Sprint planning meetings.. So we understand what our customers expectations are to a greater extend. So what we all do is producing what customer wants.
No matter what the methodology or framework we use, we design the architecture and we develop the code..With long planned frameworks what I see is that the developers have more time for creativity.. true.. But it enables more risk of over engineering.. Which result much more risk of sacrificing quality or delivery times at the latter stage of the project which results the project failures. May be soem most important part of the project ... who knows...Especially those long planed methodologies commit on specific strict deadlines.
In this case I think by using SCRUM one can eliminate those over engineering and risk of schedule overruns at the latter stage..In the same time it enables the “Defined creativity” :-)

if somebody needs to be much creative about a features or a piece of code, they can even discuss this at the daily scrum meeting.. making it transparent.. adjusting the calories of the sprint backlog. “Yeah I hear you techies.. That’s not the tech thingies work right ...LOL...!!! But unfortunately that’s the way the “bottom line” works :-) there are tradeoffs …
Now that I wrote about this, I need to explain few problems I see in SCRUM.. I see some of the practitioners believe scrum like a religion.. But thats not right.,.. As I say in my own words. SCRUM is not god given.. Its still evolving as a framework and still we see many issues.. Following are some of the issues I saw when practicing scrum.
Agile doesn’t fit for everybody . we have few left alone people when we introduce Agile Practice to corporate
The customer needs to be well educated.. Yeah .. they say “Think Agile” but never works that way.. need proper discussions and the understanding with the product owner before providing that much of transparency. Otherwise this will make your project and life miserable.
In the same time it’s a stress to commit to 8 hour work tasks everyday.. I know few guys who plan their sprints with 6, 7 hour tasks. May be that’s a solution.. but teams need to mature a bit to work with that.
Sometimes introducing gaps between sprints also helps and teams needs to be cared more when practicing scrum.

Implimenting SCRUM in my new company

I changed the job.. So what ?????
Changing the job was sort of a nerve breaking decision
But ….I did it again !..
not too bad .. for the 3rd time of my career:-)
With this decision I had to let go many things what I had.. Instead I got very interesting challenges and another new bunch of cool guys to work with....!..
Ok So I started at the new company.. I’m lucky enough it’s a startup so the start was not that hard. Lots of things to do at once… understanding the team members, skills, Projects, conflicts, risks, problems , issues…way forward , new processes (and more than anything getting used to some HR processes which I have never got used to J ) you name it !
I really appreciate the project centric culture which we are trying to build at the new company. But this needs little time to mature… No matter what.. Healthy corporate culture is very important for the people to be focused on their projects and not on other unnecessary facts and politics which I have”0” tolerance level...
Did you ask what I like the most about my new company?? Its my Note book bag.. :D Kind a cute…
Anyway that’s a different story..
What I thought to write here is that the experience of introducing SCRUM as the PM Framework to a totally new organization.
Its really a good experience. I started with one small team.. Who was quite corporative to adopt to a new way of doing things.. We created a very simple product backlog with all the user stories which need them to go through their research work. The PM (New SCRUM master )was very corporative and he found few cards which we could number as the Planning Poker card set. We started to play.. it was bit harder at first time.. But when it comes to 4th or 5th User story level the team was progressing so well. I was so thrilled to see all the silent team members talking in the planning poker session to back their idea about the user story weight.
Once we finished measuring the product backlog team created the Sprint back log. This project has only one sprint and that’s also 10 days.. Im happy that we started with a very small product backlog.
At the time of Sprint back log planning I could see some instant improvements from the team members. They worked so hard and actively as a team to get the sprint backlog planned. They decided to have the scrum meeting at 9 AM every morning..
Ok the very first Scrum day came … I was waiting… to observe their daily scrum meeting..few guys came .. they were having BF.. it was around 9.45AM still some guys are missing.. I thought.. I made a BIIG MISTAKE… Forget about scrum !! It doesn’t work…
I waited patiently till all the team members get together.. Had a very straight forward discussion.. To my surprise every team member accepted the importance of daily meeting at a specific time.. and they decided to have the everyday stand up meeting at 9.30 AM..
Ok lets see..
The next day the situation was so much better.. Almost all the team members were at office on time ready to have the meeting.. I got a skype message from the SCRUM master to come and observe the meeting.. It was a great start.. From that day onward the team progressed very well.. Understood the value of SCRUM, and value of their own team members.. Working on time boxes etc.. Currently they are about to complete the burn down of the sprint and seems they had a very good sprint.
Ok .. I think 10% of things I wanted to do was done with it.. the next task is to standardized the templates, artifacts and document the process and add them to the company process library..
The Next team situation was so much different. The Project was already initiated and that’s bit of a complicated case which I will study more and write in my next post…

Planning Poker - the problem continues…

Sorry guys still I didn't find sufficient answers to post here for the previous post I posted about problems when playing Planning poker.. I will provide answers once I find some good and logical explanations..
Now I have a new problem…. There you go… :
When Playing planning poker the team express ideas in front of the product owner to come in to a conclusion about the weight of user stories, clarifications, etc.
We do not have programmed robots in our teams to have same level of knowledge and skills. Though SCRUM is for good for good developers, ( Or even Software development is good for good developers according to Ken Schwaber - SCRUMforTEAMSYSTEM) in reality we get a mix to our teams..
So after observing the discussions going on …there is a product owner who says… Look I don't want guy X and Y in this team.. I need another like guy Z instead of X and Y . then we can burn down the back log more faster in sprints.. You guys agree to burn down only this amount in this sprint because your guys are not experienced. In traditional Project management what we do is we colour all our user front ending with really experienced and good guys and get the project delivered some way or the other. In SCRUM as we produce this much of transparency, Anybody who faced this issue and could you please explain how to overcome this issue..?

Problem I faced with Planning Poker

I copied this cartoon from www.implementingscrum.com.. Im a cartoon freek.. and thrilled to see SCRUM in cartoons...:-)

We played planning Poker for the 1st time and following are the problems I faced.. I will find the answers for these questions from experts and post them here later..

1. When Moderator reads 1 story we kept playing Poker and came out of an estimation to that specific story., But when we went through the PB more and more., team wanted to revise the previous story estimates again as its a comparative thing., How do you handle this situation?
Do you get the team to analyze the PB before coming to Planning poker so they will be more or less accurate with their comparative guess with other user stories in the rest of the product backlog?

2.There was one user story which we had to purchase some device for that. Scrum master ask where do we do the procurement management, planning , Cost estimation etc, Will SCRUM has some guidelines for procurement management for the project.

3. Customer who acted as the product owner didnt have answers for some of the questions.. there were situations such as I need to check with my infrastructure guys.. I need to ask my BI manager etc. How do you tackle that situation?

4. for certain stories we felt that we need the use cases or further analysis before thinking of their weight. ..

5. Looking at from the Project Office I saw many team for many projects they had different type of assessments. As an Example., same story "User needs to log in to the site and fill the registration form" was rated by the Team A as 5 and Team B as 20.. so how do I compare and see each team performance from the top when I look at my teams product burn down charts?

How to play Planning Poker

Planning Poker is a game which help us to do planning in Scrum. We can use it for adding the weight to the user stories.
Ok this is how it is played..
1. Scrum master get ready with the Planning Poker card pack for each member of the team who participate this session
a. Those cards should have numbers such as 0,1/2 ,1,2,3,5,8,13,20,40,100. (Why these numbers ? Let me find out and tell you .. : )
b. Write the Numbers large so it is visible when needed.
2. Appoint a moderator (Can be anybody)
3. Ask the Product Owner to come to the Session ( He doesn't play Poker)
4. Moderate Read out the 1st User story
5. Team members question the Product Owner about the story and Product owner answer them
6. After all questions are answered, each estimator privately selects a card representing his or her estimate.
7. When everybody is ready all the members put selected card to the table.
8. There can be major variations., one member may have selected 2 while the other person has selected 5
9. Then they give reasons for selecting those numbers. One may think there is some additional research needed to perform the task., another may have thought much more easier way to do that task
10. Once all these points are discussed and asked the questions from the product owner, again the team play the Poker - This time its expected it to be more similar numbers
11. Of the numbers are not quite satisfactory it goes through another round. In normally you play the game for 2 rounds per story point. But there is no rule for that.
12. In last round if everybody comes with 3 and only one person comes with 5., we ask him or her whether she is agreeable to estimate the weight points as 3. If she agrees , we have no issue., if she doesn't agree we need to listen to the reasons.
i. Planning Poker brings Multiple experts opinion to the table
ii. It has the team buy in for the final decision
iii. Averaging Individual estimates lead to better results
iv. Its more fun than just traditional project estimation by Project Managers and few senior members of the team

- This idea is extracted from Mike Cohn's Agile estimation and planning.

Planning Poker for distant team members

This is a great Idea.. How do you play planing poker if some or all the team members have a problem of getting to one location physically.. Which is always the situation in my case

I found this online Planning Poker game.. .. :-)

http://www.mountaingoatsoftware.com/page/26

WOW !! will it really work.. ? I think soo...

Problems when playing Planning Poker.

We played Planning Poker for the 1st time and I experienced the following situations.
But It was really great. I think that does the purpose. I will try to find the answers for the following problems I faced and post them in the blog..


1. When Moderator reads 1 story we kept playing Poker and came out of an estimation to that specific story., But when we went through the PB more and more., team wanted to revise the previous story estimates again as its a comparative thing., How do you handle this situation?
Do you get the team to analyze the PB before coming to Planning poker so they will be more or less accurate with their comparative guess with other user stories in the rest of the product backlog?

2.There was one user story which we had to purchase some device for that. Scrum master ask where do we do the procurement management planning, Cost estimation etc, Will SCRUM has some guidelines for
procurement management for the project.

3. Customer who acted as the product owner didnt have answers for some of the questions.. there were situations such as I need to check with my infrastructure guys.. I need to ask my BI manager etc. How do you tackle that situation?

4. for certain stories we felt that we need the use cases or further analysis before thinking of their weight. ..

5. Looking at from the Project Office I saw many team for many projects they had different type of assessments. As an Example., same story "User needs to log in to the site and fill the registration
form" was rated by the Team A as 5 and Team B as 20.. so how do I compare and see each team performance from the top when I look at my teams product burn down charts?

PMBOK or RUP ?

Im sure you are one of them... Just like me.. Just lost in between SCRUM and PMBOK ways.Which way to go.. Both are good .. Both have its - points too. This is a great article which I found and I'm sure this will help most of you readers up to an extend..

"Many organizations wish to standardize their software engineering practices as well as their project management (PM) practices, and two well-known processes are available to help in both these areas, respectively. The IBM® Rational® Unified Process,® or RUP®, offers a prescriptive approach for standardizing on software engineering best practices, and the Project Management Institute® (PMI®) Guide to the Project Management Body of Knowledge® (PMBOK®) offers a descriptive approach for standardizing on project management best practices. With both these approaches available to organizations, the question becomes: Are they compatible? The simple answer is, "Yes."

http://www.ibm.com/developerworks/rational/library/4721.html

But have you seen RUP is practiced as RUP anywhere.. I haven't seen..Because RUP does not cover all the aspects of Project management as a whole. There are many specific agile PM methodologies which are elaborated from RUP which is practiced successfully in the industry.. SCRUM is almost every agile lovers favorite toy at the moment...

I will post a presentation about the comparison between both methodologies in near future.. ( Yeah I hear you I promise a lot and never deliver .. Bad Me!!! ) But this is something which Im working on right now..so I will keep up to my word :-)

Free Scrum tool - Great

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…

Easy Scrum – 3 Don’t let this happen

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..

Easy Scrum – 2

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 21^st. 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

Easy Scrum - 1

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.