scrum.boulevart.be

I’ve been working the last few years on making a Microsoft Excel 2007 based Product Backlog template (macro’s enabled).  After 1 year i came up with the following version which is used in all our projects to the satisfaction of both our scrummasters, product managers and customers.

If you have any questions, please contact me as I did not have the time to make a detailed help document on this.  I’ll try to come up with a help document in the following week.

scrum-backlog-template-v2008-v13-1

We’re implementing Scrum as a process framework for the development of our projects. We’re iteratively implementing it, sprint for sprint. Therefore, this is not a post on how we do Scrum, rather it is a post on why we’re implementing it.

Reason 1:  It’s agile
It’s so fundamental that I’m not going to justify this with a real number, even. It gets a null. We rarely have a complete picture of where we are going when starting a project or a product. Thus, we need an agile approach that supports making discoveries while underway that can, and will, be included in the continuous planning process of the project.

Reason 2 : It’s a framework
That sounds ambiguous, but nevertheless, it’s of the most vital importance for our choice. Admitting that the process of creating great software is an intellectual process, you don’t want a full-fledged (big M) Methodology to govern and control you, just as little as you’d want that if you are trying to be a great novelist (another intellectual undertaking). You want to provide room for, and focus on, the day-to-day contributions and decisions from the development team, not the general approach solutions governed by a Methodology. We want a light-weight framework of simple rules for inducing our great potential as software designers and developers. We are so naive to assume that every employee wants to do their best, and that any rules, processes and frameworks that exists should be there to help them perform at the peak of their potential, rather than see to it that they do their work as they should. We believe the values and processes of Scrum supports this approach.

Reason 3 : Power to the people.
Day-to-day decisions — this is where the magic happens. Scrum realizes and supports this. During the sprint the developers are empowered, and they are able to do their jobs with minimal outside interference. The communication within the team is continuous as daily “Scrums” (short status meetings with no reporting, max. 15 min. regardless of team size) ensure that everyone is clear on daily objectives and progress, with minimal overhead.

Reason 4: Natural selection
Before every sprint (month long development cycles), new priorities are applied to the functionality wish-list (the product backlog) by the product owner. Only the tasks that will create the most value for the business objectives for the software will be put into the next sprint. When the sprint is full, no more tasks are added. This ensures a few vital properties of the project. 1) Natural selection. Low-value functionality in the wish-list will sink to the bottom and into the black hole. This is good, as no coders wants to code low-value functionality, and no product owners wants to pay for it, at least not before having the more important functionality working really well. 2) Just before the sprint, we can use the experience from previous sprints to do better estimation and we know more about the project, so we’ll plan better too.

Reason 5: Done
Scrum emphasizes the value of Done, with a capital D. During “The Demo” at the end of each sprint, no functionality that is “almost done” is given any attention. The goal is to get to Done (potentially ready for production) on all tasks committed to in the sprint. Thus, Scrum applies a focus on doing one thing right before doing four things half-assed. We value this as fundamental and as an imperative attribute of great software development.

Reason 6: Continuous improvement
The retrospect provides a great opportunity for self-improvement. We talk about what went good, and we talk about what can be improved. There should always be something to improve. We pick the most important improvement suggestions, and put them into the next sprint backlog to improve it during the next sprint. Not all improvement suggestions are acted on, but just having heard them sometimes makes all the difference. Scrum provides a placeholder for this activity which we cherish as one of the most important ones for being able to continuously improve the way we work.

Scrum does not allow for any detailed planning for longer than 30 days at a time. So how can you make a list of functionality that will be implemented within 3 months? Short answer, you can’t. If you do, it’s not Scrum, nor is it agile and it is the same as playing at the lottery

Old style waterfall planning let’s you promise:
A) “Within 3 months you’ll have this list of functionality fully functional and ready for launch. (insert impressively long wish-list here)”

Scrum planning let’s you promise:
B) “Within 3 months we’ve shipped three increments of the product. We’ve been focusing only on the most important functionality, so some less important functionality are likely to be missing. But the important ones are there, and they are working properly, leaving your most important and current business goals taken care of.”

History of software development using waterfall planning, shows us that the “A”-promise really is more of a “wouldn’t it be nice if”-statement. It sounds a lot better on a contract, but then that’s also all it does. Research into the software development process has shown us a few things.

1. Up-front and long-term planning misses the target as implicit requirements explode once the implementation of explicit requirements starts to evolve. If you’re a developer, you know what I’m talking about. It’s all those nitty gritty requirement details that no-one was able to grasp or visualize during planning.
2. A 25% increase in requirements complexity yields a 100% increase in solution complexity. Considering this (not indisputable) fact in addition to the first, it does not take long to figure out why the software development industry is know for its hampering of budgets and deadlines.

Benefiting from the Pareto principle, Scrum lets the less important features (likely 25% or more of the requirements) stay at the bottom of the priority list where they belong. Implicit requirements are added to the list (product backlog) during each sprint. The product owner (the customer) sorts the list by importance, pushing the less important features over the edge and spiraling down into the black hole. This, to some perhaps paradoxically, increases the likelihood of hitting business targets with the most important explicit and implicit requirements considered.

The caveat of Scrum is that upon delivery you have with no more probability fulfilled the list of functional requirements initially provided by the customer (they tend to provide such a list). But considering that we humans tend to wish for more than we can consume, and by following a process that helps us weed out the low priority functionality, it is more than likely that no-one will miss it as it’s never introduced. It has given way for a higher purpose, as the implicit requirements discovered during development tend to root in a higher understanding of the business goals, and are of higher importance than most items in the initial functionality list.

With Scrum (and similar agile approaches), we argue that the product is more likely to be ready for launch, on time, major functionality included. Not necessarily precisely as the initial intention, but closer to the current intention. And most important: Business targets accomplished.

Product or project backlog is perhaps the single most important artifact in an Scrum project. Here is a quick FAQ style introduction to product or a project backlog:

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 Scrum 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 means of MoSCoW prioritisation (Must Have, Should Have, Could Have, Won’t have this time) together with business value.

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.

 

No Scrum Traditional Project Management Scrum and General Benefits:     1. Adaptive Predictive 2. Empirical Approach Liner Approach 3. More Frequent Reviews Review before or after delivery 4. Open and Transparent Closed, hiding behind documents and unrealistic planning tools 5. Light Weight Heavy Weight Scrum and Benefits for Customers     6. Potentially shippable Product delivery after every 2 weeks or 4 weeks Potentially Shippable Product delivery at the end of the project 7. Frequently Customers can ensure that what they were expecting is what they are getting by monitoring the progress frequently. Customer can only review what they were expecting is what they got or not at the end of the delivery. 8. Customer need not to risk for committing and paying the funds without looking at actual progress of the delivery. Customer has to commit and pay the funds phase wise without looking at the actual progress of the product. 9. Customer can start using the prioritized functionalities which creates business value. Customer cannot use the product features until the completion of the product. 10. Customers can determine the product cost based on the progress and during the development. Customer will be decided at the beginning of the development for some agreed upon amount. 11 Allows Continual Inspection, adaptation, Self organization, and emergence of innovation. Not Self organizing but managed teams 12 Customers can set development Priorities at the beginning of every sprint. Can’t go with priorities 13 As Customers are involved frequent reviews which updates them about the progress, good, bad. Based on the same Customers can change their minds without paying heavy costs Customers will be updated with Reports Till the end of the project. Scrum and Benefits for Service Providers     14. Delivery high quality work Delivery Average quality work 15. Gain the Trust of customer Very low number of projects succeds and who faild lost customer trust 16. Customer Satisfaction Unsatisfied Customer 17. Get More Business If not successfull, Loose customer  

 

 

 

 

Estimating is one of the core activities in Scrum and other agile processes. This means the process of assessing the size of a story, i.e. how long it will take, how much work it is to implement, how expensive it is, or however you want to put it.

In Scrum, estimating is a team activity. For each story, the whole team participates in the estimation process.

Planning poker is a simple but powerful tool that makes team-estimating faster, more accurate, and more fun. The term was coined by James Grenning and popularized by Mike Cohn.

You can order your deck of planning poker cards at Crisp

When we talk about the estimates, we come across with questions like how do we estimate? What approach to be followed? How accurate they will be? Who are the better people for estimating? I estimated that the feature but it went beyond the estimated duration. Why?

The Scrum Team has to make very serious commitment to complete the work (Potentially shippable Product) which requires careful thought to be successful.

Steps for successful estimation:

Estimate Team’s Time available for Scrum:

Estimating the time of each and every team member available for the sprint is very much important as a part of the sprint planning. When a team member estimates a given task can be completed within 8 hours which does not mean he can complete the task in one day. The fact is that no one will seat in one place to do complete the job without attending meetings, lunch breaks, unexpected breaks, checking emails and phone calls etc.

Those who just started practicing scrum will have question regarding “Managing time for bug fixes”. Again we cannot make two sprints one for product backlog and one for bug fixes. The time for bug fixes should be addressed form the daily time available time. It means apart from daily routine work like emails, phones, breaks , you should also allocate some time for bug fixes and the remaining time you can commit for the sprint.

1. Estimate how much time each member can spend for sprint related work.

Available time for Sprint Related work = Average work day time - Time allocated for other activities.
Average work day time = e.g. 10 hours
Time Allocated for other activities: = e.g. 6 hours
Emails and Phone : 1 Hrs
Lunch : 1 Hrs
Reading Blogs : 1 Hrs
Meetings : 2 Hrs
Bug fixes : 1 hrs
Available time for Sprint Related work = 4 hours

Estimate Effort for Each Prioritized Item on the Product Backlog by means of planning poker:

Estimates can be better done by the people who have the experience of similar kind of work already done, Peers and Historical data. It is always better to involve the people who have similar work experience for appropriate estimations.

No one will estimate perfectly for the first time, for sure team members will either over estimate or under estimate the task work, but it makes them realize how much they can produce and for next sprint the team members will try to estimate a bit more precisely.

After three to four sprints, team members will be in a position to understand their own strength and how much work they can do. This leads for better estimates.

2. All the team members must participate in the estimation game (planning poker)

3. Take the prioritized Item from Product Back Log, Understand it thoroughly, what is supposed to be done, any dependencies, complexity, Risk involved, etc. ,. If required get the clarification from the product manager (Pre- Planning).

4. Divide the Prioritized/Understood Item and break it down to individual tasks.

5. Use Planning poker for estimating duration for individual tasks.

a. All the team members must have cards: ½,1,2,3,5,8,13,20,40, 100, ?, Coffeecup
b. Scrum Master reads description of the backlog Item.
c. Everyone selects and simultaneously shows cards
d. If estimates vary significantly, high and low estimators briefly explain why they have estimated so.
e. Repeat steps 3-5 until estimates stop converging.
f. Decide estimate for backlog item
g. Move to next backlog item.

Points to be consider for estimations:

1. Once committed to the sprint work, Team members should not be disturbed by adding additional work or different work then assigned to the team members.

2. Remaining work should be carry forwarded to the next sprint (This happens generally due to underestimates) .

3. Teams must be self organized and have transparency among the team members for achieving the goal.

Follow Scrum Rules to Make your Product Development Successful:

1. Full-Time Product Owner (with Expertise and Authority) Identified
2. Product Owner Works With Team and All Other Stakeholders
3. Product Backlog Created and Managed by Product Owner
4. Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
5. Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
6. Regular Sprint Length (no more than 30 days)
7. Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
8. Sprint Burndown Chart
9. Team Room with All Needed Equipment and Supplies
10. Retrospective Meeting for Process Improvements
11. Definition of “Done”
12. Commitment Velocity Calculated (from Sprint Backlog Estimates)
13. Team Size (min 2, max 12)
14. Cross-Functional Team Including ScrumMaster and Product Owner
15. Team Self-Organization - Team Members Volunteer for Tasks
16. ScrumMaster Tracking and Removing Obstacles
17. Team Safety - No Interruptions to Team’s Work During Sprints
18. No “Break” Between Sprints
19. Sustainable Pace - Timebox Effort, Not Just Schedule
20. Quality is Not Negotiable - Defects Go on Top of Product Backlog

Summary:

Team understands the details of what the Product Owner has prioritized on the product backlog in the Sprint Pre Planning Meeting:, Team decides how much productive time it has available during the sprint, Team decides how many Product Backlog items it can commit to complete during the Sprint. , And finally team delivers potentially shippable product at the end of every sprint.

References:

1. http://www.scrumprimer.com/scrumprimer.pdf
2. Memories of ScrumMaster Training by Pete Deemer
3. http://www.agileadvice.com/archives/2007/05/scrum_rules.html

To my opinion at least one of the following items should be variable in order to deliver a successful project:

1. -Timing
2. - Budget
3. - Quality
4. - Scope

During my 15 years as a project manager (the last 5 years in e-marketing), I believe that it is easier to have the scope variable rather than timing or budget.   Especially as ideas change over time of the project.

In e-marketing (and web projects) timing is crucial so this is no option to make it variable as the campaign starts at a certain point in time.  The same is true for budget.  It is always very difficult to have your stakeholder ask extra budget to his/her boss.  The solution for this is to have the scope variable with priorities.  I define the scope by means of user stories and than prioritize them together with the stakeholder as Must Have’s, Should Haves, Could Haves and Won’t haves this time.

The Must Haves are necessary in the project to be successful, the Should and Could Haves are the items that we can play with in order to embrace change during the project.  In this case it is easier to tell you boss that a certain could have is dropped in order to stay within budget rather than asking for extra budget.  This functionality was probably not critical to deliver a successful project.

The Should and Could have’s probably will change during progress of the project.  Sometime extra stories arise so that we can add them and remove some minor other stories in order to keep everything within budget and timing.