Scrum is a framework for agile project management – there are many resources about Scrum on the Internet. A nice summary is the following one, taken from the website of agile42, where you can also find a one-page introduction to Scrum:
“Scrum is an iterative and incremental process for product development and the organization of teams. Tasks will be achieved faster and with higher quality with the aid of the Scrum-Framework. This is possible because of the high self-motivation of the team, which chooses itself how the tasks will be executed. The customer demands will be iterative prioritized and quickly realized.“
How does Scrum work for Phoenix?
One of the basic ideas of the agile approach is to develop a product step by step by focusing on the most important features first. Since TYPO3 Phoenix will have a wide range of features, we started with a role-based mind map of use-cases in order to have a better overview and to discuss priorities. The mind map is a base for the product backlog of Phoenix. In Scrum-lingo the “product backlog” is a list of all features the product should have. Currently it contains the next user stories and the upcoming features as “epics”.
The Scrum Team
Scrum is based on three roles, where the most important one is the “team”. The team is basically the TYPO3 Phoenix core team: a group of experts around Robert Lemke and Karsten Dambekalns. This team has the challenging task to turn the scoped features into reality. The goal is to get things “done done” – in the Scrum world this means the features are not only implemented but they are tested and meet the “definition of done”. The Scrum Master for TYPO3 Phoenix is Ben van’t Ende, he takes care of the teams need's and solves impediments.
Another role in Scrum is the Product Owner. For TYPO3 Phoenix we have a product owner team consisting of experts in different areas. The product owner team meets regularly to discuss and prioritize the next features and to update the user-stories in the product backlog.
New members who are motivated and interested in building TYPO3 Phoenix are very welcome . The Scrum setup helps new members find relevant and interesting tasks and to get deeper into the different areas.
Definition of Done
FLOW3 and TYPO3 Phoenix focus heavily on quality and a reliable architecture on every level. There is also a very high ambition for a usable and consistent user-interface.
In Scrum it is important to deliver a potentially shippable product increment after each sprint, that meets the defined acceptance criteria from the sprint-planning and the “definition of done”. The “definition of done” is defined and committed to by the team and has a set of characteristics that should be fully met for each task. For TYPO3 Phoenix the definition of done is maintained in the wiki and some key-criteria are:
- Clean and simple code, covered by Unit-Tests
- No workaround used and and no technical debt opened
- Documentation is updated whenever necessary
- Selenium tests are used for functional end-to-end browser tests. (Selenium is a test framework for web applications that allows interaction with a browser.)
At the end of a sprint the finished stories are deployed to the integration system , where the Selenium tests are executed as well.
The deployment is done with the help of an automated build process, which is triggered by a continuous integration system*.
Organization and Meetings
Using Scrum in a distributed team to develop an Open-Source CMS is unique and new but the strong engagement of all team members and the possibilities of the web make its success possible. Here is what we do:
- A sprint length between 5-6 weeks is used.
- For sprint planning, sprint review and retrospective, a Webex Meeting is used to meet virtually and share desktops.
- TYPO3 events are used to discuss topics in person whenever possible.
- There is a Jabber chat room, which is used by everyone currently working on tasks in order to discuss things quickly and to stay in touch.
- A daily Scrum call at 17:30 is used to do the daily Scrum. Minutes from the daily Scrum are sent to the mailing list for those who could not attend.
- Instead of using a Scrum board, we currently maintain the sprint backlog at forge.typo3.org.
What we did so far
Currently we can look back on 2 completed sprints and one that is in progress. We’ll gain confidence in the Scrum Team by looking at the results.
Sprint 1:
The goal of the first sprint was to start with the most basic CMS user-stories and the setup of required system environments and “build processes”. The result of the first sprint was the first real website rendered with TYPO3 Phoenix as well as a working backend login! Also some more continuous integration builds where set up: one for building and deploying the integration system and one to run the first Selenium tests for TYPO3 Phoenix!
The stories in detail were:
- As a website user I want to see a website.
- As Scrum team members we want to have a basic CI environment
- As a developer I want to have an easy API to create a page and add content to it, in order to fill and access the Content-Repository
- As an editor I want to login and have a basic editor interface available.
Sprint 2:
The features planned for the second sprint focused on the basic CMS features for pages. As a result of the second sprint you can edit page titles in the backend and you can have a working dynamic menu powered by TypoScript 2.0. Setting up a breadcrumb menu is now as simple as writing: myMenu = BreadcrumbMenu
A lot of conceptual work was done under the hood, especially for content security.
You can get a nice overview of sprint 2 as a video podcast online
Sprint 3, 4 and 5:
While the first two sprints aimed to render a basic demo website, sprint 3 focused on editing functionality. The Aloha editor provides a very easy way to edit content in a what-you-see-is-really-what-you-get manner. After the switch to Git and the introduction of a new code-reviewing tool (Gerrit) the team could also raise again the quality of the source code. This paid off immediately in sprint 4 which dealt with complex topics such as workspaces in the content repository and an improved JavaScript architecture for our ExtJS-driven user interface. In sprint 5 the team was able to present first parts of the user interface in its actual design which gives a first guess for how it will be using the new TYPO3 Phoenix backend.
Where are we going?
The next user-stories on the way deal with content editing, templating and backend object editing. After these fundamentals have been implemented, we’ll focus on more advanced features such workspace integration and localization support. As soon as the related stories for these features are “done done” there will be a useful and amazing TYPO3 Phoenix that already has most of the important CMS features.
At the current state it is hard to come up with a reliable prediction of a first TYPO3 5.0 release with all the planned components.
To give it a try here are the first release estimations:
Sprint Release 10: Workspace support, most of the content editing features
First basic burn-up chart
You can see that TYPO3 5.0 gets closer and closer. A first usage for pilot projects that not only require FLOW3 but also basic CMS features could be possible by the end of 2011. We have a great team, which is motivated and skilled to implement the planned features. With the scrum process we have high transparency of the current state and the next planned steps – so be curious about the next releases or get involved in the progress..
Gimme five!
* Continuous integration (CI) implements continuous processes of applying quality control, like automatic building the project from SVN and running all Tests.
* This article is simultaneously published in T3N, the German TYPO3 magazine.