Codendi Blog

Once you’ve completed Step #3 and clarified the requirements for all the Product Backlog items targeted for your Sprint, the next step is to plan the Sprint in detail…

Sprint Planning Workshop (Part 2)
The first part of the Sprint Planning Workshop (in the last step of this series) was focused on clarifying the requirements for the selected Product Backlog. The second part of the Sprint Planning Workshop is focused on breaking the requirements into tasks and estimating the hours required to complete them.
Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day. This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
Make sure the meeting is attended by all team members.
The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered. However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.

Set the Sprint Budget
First of all, calculate the team’s Sprint Budget. This is the available number of hours the team has to work on the Sprint. Start by multiplying the available hours in the Sprint Duration by the number of full-time people in the Sprint. Then, make any reasonable deductions for time that team members will not be able to spend working on the Sprint. Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc.

Break Requirements into Tasks
Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
Each of these tasks, especially development, may be broken down further. Maybe to a component level detailing each of the individual elements of the software architecture that will be required to deliver the feature of the product.

Include all tasks necessary to make the Product Backlog item 100% complete – i.e. potentially shippable – within the Sprint. Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
State tasks as deliverables, if at all possible. Deliverables are more measurable than tasks. Instead of describing what you’re going to do, describe what you’re going to deliver.

Estimate Tasks in Hours
Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice. Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
Firstly, breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result. Secondly, tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.

Commit to the Sprint Backlog
Add up all the task estimates for the selected Product Backlog.
If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint. Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog. The team should commit to delivering the Sprint Backlog.

Identify Stretch Tasks
Sometimes teams under-commit or over-estimate. Stranger things have happened!
Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved. This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!

Next…
So now you’ve got your backlog in order, estimated your backlog, clarified your requirements, and planned your sprint. Now you’re ready for step 5 – Create a collaborative workspace…

Extract from Kelly Waters’ blog

The step 3 is to plan your Sprint.

Sprint Planning Workshop
Call a Sprint Planning meeting. Make sure the meeting is attended by the whole team. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product. And very importantly the Product Owner.
The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.

Decide Your Sprint Duration
This is an important decision. Scrum suggests 30 days. It might be right. But this is one point that seems to be widely adapted by agile teams practicing Scrum.
The optimum Sprint duration depends on many factors. A development team’s ‘cycle time’ is a direct reflection of the maturity of their processes. A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle. Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who’ve become very quick at Sprint Planning), a short cycle might be very comfortable.
The range is between 1 week and 1 month. 1 week is probably the shortest that will ever be practical, although if you really master agile practices, why not ship each new feature when it’s ready?. 1 month should certainly be the longest.

For fast-moving products or markets, such as web-based products - where there is central deployment and no rollout or user training - 1 month seems like a lifetime! For example Codendi team works with 2 week Sprints.

Keep Sprint Duration Consistent
Whatever Sprint duration you choose to go for, keep it consistent.
This, in fact, is more important than the length itself. Because it’s this consistency that allows you to get into a rythm. It’s this consistency that makes your process very repeatable. And therefore helps you to get into your stride as a team. And it’s this consistency that allows you to start understanding how many Product Backlog points you can typically do in a Sprint.

Once you’ve decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.

Select Target Backlog for Sprint
Now you’ve decided on your Sprint duration. Next you must decide on the goal for the Sprint…
Looking at the top section of the Product Backlog, what would seem to be a reasonable goal to set for the Sprint? Can you express an objective that sums up the goal for the next Sprint, or at least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?

Select your target backlog for the Sprint. Make this decision as a team.
Include a bit more than you think can be achieved. It’s important to prepare more items during planning in case the team finishes early. These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed. These are the things you will only do if the Sprint goes better than you expected.
In future Sprints, you will be able to use your Scrum team’s previous Velocity to help with this decision. Velocity is the number of Product Backlog Points delivered in a Sprint. This tends to fluctuate wildly early on when adopting Scrum. But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.

Clarify Sprint Requirements
Take each item on the Product Backlog. It’s important to go through them methodically, one item at a time…
The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
The whole team discusses the item in detail. The whole team asks questions about the feature in order to establish what it should do and how it should work.
The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
You can use whatever form of writing requirements you want to. But the important principle in Scrum, and in any agile development methodology, is that you write requirements feature by feature, just before they are developed.
Write requirements in a way that is lightweight and visual. Agile requirements should be barely sufficient. The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.

Consider writing ‘User Stories’, a concept from XP (extreme programming). It’s beyond the scope of this article to explain user stories in any detail. But the basic concept is to write features using this construct: As a [type of user], I want to [do whatever], so I can [achieve what goal].

Extract from Kelly Waters’ blog

If you’ve completed step 1, congratulations! Because it’s the biggest step. If you haven’t completed step 1, you must not go any further until you have. So here’s Step #2: How to estimate your Product Backlog…

High Level Estimates

You need to provide some high-level initial estimates, in order to get an idea of the size of your product backlog items.
This is helpful because it helps to inform the decision about priorities. And whether or not the features are likely to be worthwhile. And from a management point of view, gives a perspective of how big the team ought to be, commercials permitting.

But as yet, you don’t know much about the items on the backlog. You don’t know exactly what the features are meant to do. You don’t know what tasks are needed to complete them. And you don’t really know how you will implement them.
So you have to do a very high level, top down, indicative estimate.

Estimate Product Backlog in Points

The answer: Estimate your product backlog in points. Not in units of time. Estimate your product backlog in points. So we’re not asking the team ‘how long will it take?’. We’re asking ‘how big is it?’

Use a Points System

So what scale should you use for your points system?
For the sake of simplicity, when using numbers for indicating size, use the range 1-21. Certainly for bug fixes and enhancements on products in the BAU (Business As Usual) cycle, this should give you sufficient a range.
The key here is about relativity.

A backlog item describes a feature. Maybe, for example, it’s a report. You’ve done similar reports before, but it does have some complexity in the underlying data, so you decide to call this a 3. Next on the backlog is another report. You size this one relative to the other one. Is it bigger or smaller. Clearly 21 is a lot bigger. 2 is a bit smaller. And so on.

To make sure the scale works for you, start by picking what you think is the smallest thing on the backlog. Give this a 1. Then find the thing you think is the biggest thing on the backlog. Give this a 21.
When you get further down the backlog, you’ll get to a point where the items are really rather fuzzy. And rather low priority. In fact you not sure you’ll ever get to them in your lifetime. Please don’t feel you have to size the entire backlog. Size enough of the items to see you through the foreseeable future. Remember it’s already been put in priority order. So make sure you work from the top.

Estimate as a Team

Size your backlog as a team. Each team member writes their estimate on a card, and everyone shows their answer at the same time. It helps to ensure less experienced members of the team are equally engaged and are not over-influenced by more experienced team members. It also helps less experienced estimators to learn from others. And it helps to avoid stronger, more vocal characters having too over-bearing an influence on the result.
From this exercise, negotiate the size of each backlog item as a team.

Review Priorities
Once you’ve sized up the backlog - or enough of it - ask the Product Owner to have another quick look at priorities. Maybe now they can see the relative size of the features they’ve asked for, they might change their view of priorities. ‘Wow, if that’s a 21, I’d rather have the other stuff first’, or ‘if that’s only a 2, let’s get it in the next release’. If any priorities are changed, simply move the item’s position in the order of the backlog.

Extract from Kelly Water’s blog

This is not only the 1st step. It’s the most important step.

Align with Business
Firstly, before you do anything else, you must align your development team with the business.

If you’re part of a business unit, that might be natural and straightforward. If you’re a central development organisation serving multiple business units, developing multiple products, it might be harder. Initially, make sure you have at least 1 person dedicated to a product, application or product range where you will start implementing Scrum.

You can share a team split across multiple products. But it’s a little harder and therefore is a slightly more advanced technique. If possible, it would be ideal to avoid this situation in your first implementation of Scrum, if you can.

Start with BAU

Secondly, although you can use Scrum on projects to good effect, you should start with BAU (business-as-usual) rather than on big projects. This will keep things simple while you and the team get used to the basics.

So you’ve decided on a product where you will start using Scrum. You have at least 1 person who will be dedicated to that product (or product range). To keep things simple at first, you have selected a product that is in the BAU cycle of bug fixing and enhancements.

Find a Willing Product Owner

The next key step is to nominate a Product Owner. You must find 1 Product Owner. 1 person who will be responsible for prioritising work on the product. 1 person who knows what is required of the product. 1 person that is a good communicator and able to convey requirements. 1 person who is committed to the success of the product, such that they are willing and able to dedicated a reasonable amount of time to its development.

If, for whatever reasons, this step is a problem for you, DO NOT PASS GO.

If you can’t complete this step, your product development is likely to be fraught with issues. Whether or not you implement Scrum. Unless you can take the above steps, it’s quite possible you will be faced with a barrage of requests, no clear view of priorities, a lack of clarity about requirements, lots of noise and complaints, and being pulled from pillar to post. The consequences? You don’t deliver and/or fail to meet expectations. Everyone is miserable. And somehow it’s all your fault! Unfortunately, this is all too common a situation for development teams everywhere. This must be solved before you proceed. This is a critical success factor for your team.

Act as ScrumMaster

So now you are organised. You’re aligned. You have 1 product, application or product range. You have at least 1 person dedicated to the product (Scrum Team). You have 1 Product Owner. And you, by virtue of the fact that you’re reading this information about implementing Scrum, I will assume are probably the ScrumMaster.

As ScrumMaster, you are responsible for supporting the Scrum Team, coaching and guiding them through this process, and removing any impediments blocking their progress.

Create the Product Backlog

Now you must create the Product Backlog.
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order.

Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.

Only the Product Owner can prioritise the Product Backlog.

The Product Backlog can contain anything relating to the product that is : bugs. Enhancements, whole projects, issues, risks…

Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business).

Functional requirements should be expressed as features. Non-functional requirements can be put on the Backlog too, for instance ‘the product needs to be faster’, ‘we need to ensure the product is secure’, ‘we need to get off the old platform’, ‘there’s a high risk of downtime due to a single point of failure’. These might not be features, as such, but they are completely justified as items on the Product Backlog.

Prioritise the Backlog

The Product Owner prioritises the Product Backlog. He doens’t categorise the priorities 1, 2, 3 or anything like that. The priority is determined simply by the order of the list. The Product Owner puts the Product Backlog in priority order.

Things at the bottom of the list may be way off and may or may not ever get done. Things down the bottom are likely to be fuzzy and ill-defined. Don’t waste time defining things you may never get to, or not get to for some time. If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the Backlog. However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the Backlog and explain to the requester where it fits with priorities.

Extract from Kelly Water’s blog

Agile Software Development is one of the big buzzwords of the software development industry. But what exactly is agile development?

Agile development is a different way of managing software development projects. Principles of Agile Software Development, and how it fundamentally differs from a more traditional waterfall approach to software development, are as follows:

-Active user involvement is imperative
-The team must be empowered to make decisions
-Requirements evolve but the timescale is fixed
-Capture requirements at a high level; lightweight & visual
-Develop small, incremental releases and iterate
-Focus on frequent delivery of products
-Complete each feature before moving on to the next
-Apply the 80/20 rule
-Testing is integrated throughout the project lifecycle – test early and often
-A collaborative & cooperative approach between all stakeholders is essential

Extract from Kelly Water’s blog

With this article in 10 steps, you’ll understand how to concretely implement Scrum methodology with your team.
After reminding hte principles of agile development , you’ll find 10 guidelines steps for an easily deployment. Each step is developped in a dedicated article.

Share with us the questions you may have during your implementation and we’ll try to find a solution together !

- Step 1: Get your backlog in order!
- Step 2: How to estimate your product backlog
- Step 3: Sprint Planning/clarify requirements
- Step 4: Sprint Planning/estimate tasks
- Step 5: Create a collaborative workspace
- Step 6: Sprint!
- Step 7: Stand up and be counted
- Step 8: Track progress with a daily burndown chart
- Step 9: Finish when you said you would
- Step 10: Review, reflect, repeat…

Thanks to Kelly Waters who gives us these advices on her blog.

Q: What is the first step in implementing a requirements strategy?
A: A move to either introduce a requirements strategy where none currently exist or implement a different requirements strategy requires careful attention and planning to change management. As a first step it is critical to create a sense of need and urgency throughout the organization that will be affected. People know the difference between a real need and the next “silver bullet”. Establish real need in the minds of everyone involved, but don’t overlook capturing their hearts as well. Use both statistics & metrics and anecdotes to create a compelling case for change, and involve 20% of your organization in facilitating the change. A core group of knowledgeable and motivated individuals can facilitate change more rapidly than a single leader from a soap box. Finally, include in this opening salvo the training necessary to educate people on requirements development and management. [...]

Q: Who should be involved in defining and managing requirements?
A: The people who are going to use the software built from the requirements. That first sentence cuts to the chase, if you don’t have people who will use the software involved in the requirements process then the software will not be fit for the intended business purpose. However, there are multiple skill sets required to create software requirements that are usable themselves. [...]

This is an extract from an article published on Dr Dobb.

As a VP of product development , M.Witt deals with requirements every day. He recently took time to talk with Dr. Dobb’s editor in chief Jon Erickson.

Read the whole article

 Codendi 4.2 beta version is released. This is an early access from the final Codendi 4.2 Edition that will be fully tested and secured and soon available.

With this beta version, Codendi provides a new generation of trackers, one of the most important tool of the platform on which are based all the other tools. This is the major new feature of Codendi 4.2. Codendi team worked hard to build a new tracker engine providing from now significant enhancements and new functionalities and allowing lots of future developments.

The trackers of the platform had already strong capabilities as linking all the artifacts of a project to each others allowing users to immediately access work items, bugs, source code, documents and other artifacts at any step of the project’s lifecycle.
Codendi 4.2 beta version goes further and provides now a workflow for each tracker. It is now possible to define artifact state transitions with associated permissions. The 4.2 beta tracker engine offers new tracker templates and the import/export of tracker structure in XML format to boost open architecture.

For improving project monitoring and productivity, you can now post results or reports of your customized tracker queries everywhere in your project or personal workspace. You can interactively build up reports by adding, moving and resizing columns. You can also add and remove query filters interactively and replay previous complex queries very quickly. Moreover, the new user-friendly interface makes work easier and faster.

A GIT plugin has been added. This distributed version control system offers performance and efficient storage. It allows committing offline then pushing, branching and merging are faster and easier. Git enables multiple local branches that can be entirely independent of each other. Git enables to link a repository to several other remote ones which can be modified locally as independent branches. Each remote branch can be a feature you can experiment and finally decide to merge or discard.

Codendi final 4.2 Edition will contain bug fixing and a new SOAP interface to give the possibility to plug any other tool to the platform.

You are kindly welcome to download the Codendi 4.2 Beta version and share your feedback on the community website http://www.codendi.org/

Codendi offers a new service, Codendi SaaS.

In order to manage and follow the projects on the Codendi platform without having to manage the installation, maintenance or reliability aspects, or the environment security, Codendi allows its customers to benefit from a Codendi platform based on an external server.

Indeed, Codendi SaaS is hosted by Xerox, and is managed by an experimented team in charge of the application, leaning on a robust and secured infrastructure.

The support is carried out by our development and support teams, in order to facilitate the use of the solution to the Codendi SaaS members, wherever they are connecting to.

Codendi SaaS is quickly useful, allows a good scalability and interoperability between the actors of the project. Those actors can work in the same company, or can be customers, providers or partners.

SupInfo has selected this year Codendi Saas to help its students to achieve the internship projects they have to realize. This service allows them to share the project with the concerned companies, and to benefit from the latest releases and versions of Codendi.

SaaS, for “Software as a service”, is a service which consists in hosting an application on its own server for its customer use.

The INRIA (the French national institute for research in computer science and control) in Grenoble has animated on 12th January a seminar about the methodologies and experiences of the open source based developments.

This meeting, organized by the business intelligence Club IN Tech and GRILOG association (“Grenoble Isère Logiciel”, i.e. Grenoble Isère Software), was the occasion for the different actors, industrialists and researchers, to have a technological and information exchange.

During this conference, a demonstration session has allowed to present open source applications and products, and to discuss the development team organization, the features used, or the technology transfer among others.

Nicolas Guérin, our technical manager, has presented Codendi and its evolution : from the forge created inside the Xerox research center in order to gather all the required tools of the software development to a natural passage to an ALM tool.

Actually, the proprietary ALM solutions are generally complex, split and expensive. The approach proposed by the modern forge developers allows a natural integration of the ALM tools, as :

• the project standardization thanks to the patterns
• the possibility of parameter setting following the chosen methods (Scrum or other Agile methods, CMMI or quality)
• Or even the traceability of the requirements, tests, documents or taskswhich can be linked together.

Besides, the open source development opens up possibilities to integrate and adapt other tools to increase and diversify the features as Subversion, Git, CVS for versioning, Hudson for continuous integration, or Salomé TMF for test plan management.

The open source process makes easier the use of protocols and open standards as HTTP, XMPP, SOAP or LDAP.

Finally, it improves the contributions and the co-development model because it creates discussions with the users; so that the extensions developed were enough generic to be integrated into the application. So, all users benefit from it.

In fine, the open source is determinedly directed to the consumer, because of durability and search of innovation, and requires in return an investment in talents.

And you, what is your experience about the open source use? Share your opinions on this blog.