Product or project backlog is perhaps the single most important artifact in an Agile 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 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.

Popularity: 30%

Posted on January 15th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction, Practices | 5 Comments »

In our previous post on Set based Concurrent Engineering and Software, we discussed how the trick in Set based Concurrent Engineering (SBCE), is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. We also discussed how good design should keep options open, and how this in turn helps us to be flexible and quick to respond to challenges. One approach that many people use [in Agile, Lean and even Waterfall] is You Aren’t Gonna Need It. Like other aspects of Agile and Lean, the concept is simple. Yet, understanding and implementing it can be very difficult. This is because, the concept is against the traditional way. In this case, foreseeing and predicting the future and planning for it has been considered the hallmark of great teams. However, the concept of YAGNI and Do The Simplest Thing That Can Work (DTSTTCW), suggest that its not as much foresight of what will happen in future, but ability to respond effectively to what will happen that separates the really good teams from the average ones. In terms of software, we have always tried to design for “any and all eventualities“, while following practices that do the exact reverse. This is because, we are not designing the architecture for “any and all eventualities” but what we consider to be “any and all eventualities“. If the events unfold exactly the way we want them to, everything goes nicely. The moment there is a deviation, things go astray. In contrast with this elaborate Big Design Up Front, sometimes deferring a decision making to when you have enough information is the best thing to do.

YAGNI is a XP practice which states that “Always implement things when you actually need them, never when you just foresee that you need them.” XP actually takes it a step further and says that even if you’re totally, totally, totally sure that you’ll need a feature later on, don’t implement it now. However, to start with if you have any doubt about “whether you will need it” you should not add that feature. This is because you *might* need the feature in future, but you *might not* either, even if you are very sure right now. If you build the feature, only to discard it later - it would be waste of effort. You might actually need the feature and implement it, but you might need it in a different format and hence, would need to do some work to add to it anyways. Some other disadvantages of doing “what is not needed right now”, right now are:

• The time spent is taken from adding, testing or improving necessary functionality
• The new features must be debugged, documented, and supported
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later
• Until the feature is actually needed it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, the unnecessary feature may not work right, even if it eventually is needed
• The software becomes larger and more complicated
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a situation where you don’t know where to draw a line

As you can see the above are pretty serious issues. And we take them on in a software architecture/ project on the *promise* and *premise* that it would be useful down the road.

The above said, you can religiously follow the letter of YAGNI and yet miss the spirit of YAGNI. The idea of YAGNI is not only to not commit to decisions as late as possible but also do the minimal that could work now. If following YAGNI means that you are actually doing more work “now”, you are not following the spirit of YAGNI. Similarly, the idea of YAGNI is to keep the code simple. If doing “YAGNI” makes your code more complex, you are not following the spirit of YAGNI. For instance, committing to a database is a big decision and you would like to keep the decision open till as late as you can. However, if you already have a database persistence mechanism, not using the same and writing your own file based implementation simply because your feature “does not need it”, would only add chaos. Although, your feature does not need it and probably the feature would take more time using the database persistent mechanism but maintaining two sets of persistent mechanism has two different implementations for same work. We said that “YAGNI is simple” yet “it can be difficult to implement”. For instance, “You aren’t gonna need it” is not about making a method private because “no one will use it, never”. It’s about not putting a pluggable generic templating mechanism for different kind of outputs if your requirement just state “show static HTML”. It does not ask you to be lazy or stop thinking about a requirement. It asks you to consider if you “really need” to write you code in this way or you can simplify it can use it only for the purpose of “this requirement”. The difference is enormous.

Some of the arguments against YAGNI have been that sometimes you have to implement a certain feature, you should factor in that at present. Everything has a cost of doing right now and also the cost for not doing it right now. If the ratio is high, it would be a waste to do these features right now. If the ratio is low [i.e. cost of not doing it now is high], then in all likelihood, the requirements should be prioritized and clear your way in doing something right now. So, lets say you talk to your customer and conversation goes like this:

• Team: We see you have this requirement down in iteration 2. We think that this requirement we are doing in this iteration should factor in that requirement as well and if we took a bit of time to define the interfaces well, we would save a bit of time in iteration 2.
• Customer: Ok, how much time would you save?
• Team: Umn! Maybe 4 hours.
• Customer: And you will need to write that interface anyways?
• Team: Yes.
• Customer: Good! Tell me, if I chose not to implement this feature in iteration 2 but iteration 6, but pick these apparently related requirement from iteration 3 in iteration 2, would the work you do still be useful.
• Team: Umn! Probably yes!
• Customer: So can you code in a way that all the requirements in future iterations are taken care of right now because I don’t know what might need to be done when. Maybe, iteration 2 is pretty stable but not so sure about iteration 3 onwards.
• Team: Yes, we can. We can simply code for iteration 1 right now and not commit either to iteration 6 or 2 feature requirements right now
• Customer: Cool! Would that be YAGNI?
• Team: Err, Yeah!

This is a slightly simplified example, but the crux is that if something has this huge advantage of doing right now, then it should be a priority anyways. The above conversation could probably end with customer asking the team to do it now if the question the team posed was, “whether we should write the comments as we go or later” or “can we commit to a coding architecture right now”. This is often presented in what is called “Opportunity Cost Argument” i.e. loss of cost from other opportunities by choosing to go with only one opportunity. This can be balanced by sometimes asking “what is the cost of not choosing this opportunity right now”.

YAGNI is not a standalone concept and must be used with common sense and following good design principles, good testing framework and continuous refactoring. We like to think of YAGNI as a question and not the answer. The answer has to be provided by you. The secret is to use your brain and not reply on the letter of what the concept says but the spirit as well. This is where Agile separates itself from other processes anyways. The concept does not ask you to be blind. It only asks you to be not be a soothsayer.

Popularity: 13%

Posted on January 12th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction | 1 Comment »