Using the pre-defined Scrum process

I've recently been asked for more guidance about using the pre-defined Scrum process in version 2.9 of xProcess. It uses some of the new features for process definition (like Composite tasks) and also has "top-down" estimating for projects built-in, which is useful for resource planning and financial reporting. So I'm planning to post a series of blog entries on the process and in this one I'll focus on getting started with this process "out of the box". Here's what it covers:

• Creating a Scrum project
• Adding resources to the project
  
• Adding Sprints to the project (a Sprint in Scrum is like a "timebox" in other methods)
• Adding Backlog Items to the project (Backlog Items are the tasks the project must achieve)

So step one is to select the Project Manager perspective (the default) and hit the "New" button so we can make a Scrum project. The New project dialog shows the processes that are available for import, so if you've not already done so this is the point to import "Basic Scrum 2.9.0" and then select "Scrum Project" as your type of project. You can fill in the name and other details of the project (such as the number of 4-week Sprints and a location of a Wiki if you are using one) on this dialog.

At this point take a look at the set of tasks that are already in the project (hitting the "Tasks" button is the quickest way to do this. Here's what you might see (click on the image to make it full size).


There are:

• some overhead tasks (green because they have fixed start and end dates and are within the target dates of the project)
• A "Sprints" parent task containing one sprint "Sprint 01" (these tasks are red since they have NEVER end dates, clearly after the project target)
• An "Unscheduled Backlog" (which is grey as this task is specified as not to be scheduled, also resulting in NEVER end dates).

In the pane below the project details, you can also see there are some alerts displayed telling us that this project needs resources with particular role types. That's a clue to our next step - add resources. Hit the "Resources" button on the "Tools" pane and you'll see an "Add/New Project Resource" button. If you've already defined or imported a set of people you can select those who are going to be on the project, or you can create new persons at this point. Add six team members (Participant role) and one team leader (Scrum Master role) to the project.

At this point we should see actual end dates appearing for the Sprints and the overall project and we can even see a Gantt chart and projected Burndown chart. The Burndown chart is slightly more interesting if we add 2 more Sprints to the project (hit the "New" button and select "Sprint"). Then hit the "Burndown Chart" button on the project pane and you should see something like this:

Now it's important to note that as yet we've entered very little information about this project other than the number of Sprints and the people on the project and their availability. The projected burndown is only reflecting this simple data showing when the work in each Sprint (based on estimates for the amount of work in a Sprint which is modifiable in the process definition or, for a specific Sprint by modifying the estimates in its "Required Resources"). To use Scrum in earnest we need some actual "Backlog Items". Backlog Items are identifiable tasks that in a software development project for example could correspond to features to be built or defects to be corrected. The next step therefore is to add such items.

Hit the "New" button again and select "Backlog Item" (and then "Next"). We have a choice of the 3 Sprints we've defined or the "Unscheduled Backlog" as valid parent tasks for these items. Setting the parent task as Unscheduled Backlog means that we can create a set of tasks without them changing the scheduling of the project. We can then decide later in which Sprint specific tasks should be completed. So with Unscheduled Backlog as the parent task you can give the backlog iten a name and a size (size is measured in "ideal days" by the way), and hit "Finish" and the task will created. If you already have a list of tasks you can copy and paste a comma-separated list into the name field of the "New" dialog, check the "Create Multiple" check-box and several items will be created in one go.

Now we have a project some resources and set of tasks to be completed. The next step is prioritising. We'll look at that in the next posting in this series.

Searching the blog by topic

Blogspot offers some useful facilities for finding blog entries by topic. Below most entries there are a series of labels. Clicking on any of these will bring up other related articles on the same topic. Try it our with the labels below this post.

xProcess Europe

On November 6th Ivis announced that it had demerged its European operation (see Press Release) . The new company is known as xProcess Europe and it's owned by former members of the UK team including Andy Carmichael and Paul Kuzan both seminal thinkers in the evolution of xProcess.

Andy Carmichael: "Paul Kuzan and I are both very pleased to be involved with the on-going evolution of the xProcess product and brand, and we believe xProcess Europe provides a great opportunity, particular for developing the services offering that customers adopting xProcess are often looking for. Providing better support and expertise for companies wanting to improve the processes behind their project and portfolio management will be one of the main focuses of the new company. While our product sales and support work will primarily be targeting the European market, we will continue to offer process improvement services world-wide, wherever the needs exist."

xProcess Europe and Ivis Technologies are both supporters and contributors to this blog. From time to time you'll find links and references to both companies here. For more details try their web sites: www.ivis.com and www.xprocess.eu.com.

The Simple Process... or is it?

The Simple Process in xProcess is the first one you are likely to use. It contains basic patterns for a project, a task a timebox and so on, and it also has some useful actions in there that can be used in your own patterns or even exposed as "User Actions" so they can be called on your projects.

The Simple Process has several elements that you cannot delete as for example xProcess assumes that even if no other Role Types exist (such as Project Manager, Developer, Tester and so on) at the very least the Participant role type will exist. When you define your own process it's likely that you will inherit Simple Process patterns (though you can hide them by defining your own hidden patterns with the same name. So it's definitely worth taking a snoop at all the elements in there. You might even want to cut and paste some bits into your own processes and modify their behaviour.

Latest patterns for Scrum

xProcess 2.8 is being released this week and among the exciting new capabilities are some new sample processes, including updates to the Scrum patterns. Here are some of the highlights.

Firstly the project pattern for the "Basic Scrum" process is now built from composite tasks so that there is a standard structure that is provided for all its projects. The Hierarchy diagram shows the structure, having top-level tasks for: General and Scrum administration overheads (overheads are unplanned or unplannable tasks that take up a proportion of everyone's time); the Sprints (a composite task which contains an iteration of Sprint instances); and the Unscheduled Backlog (a composite which contains a collection of Backlog Items).


You can also see from this diagram the structure of the Sprint and Backlog Item patterns. Sprint is a collection of the Backlog Items to be scheduled over the period, and consists of a single task. The beuty of xProcess of course is that these patterns can be modified to match the way your team is working or the particular application of Scrum that you are using. For example if you are using Scrum with XP you might want to rename the Backlog Item pattern to User Story and perhaps provide some structure to the set of tasks and role types that corresponds to0 the way you are using the method.

When you make a new Scrum Project in xProcess you'll be prompted for values of the parameters of the pattern. You can see these in this screenshot, where as well as defining the name of the project the start date, duration (the number of 4 week Sprints) and the Wiki location.
The Wiki location is not a required field but we've found many people find wikis are a convenient way to group documentation. By providing the location of the wiki in this dialog the descriptions of your backlog items are automatically transferred to a wiki page while also being browsable and editable in xProcess views.

Having created your Scrum project from this pattern, the next thing to do is add your resources. You need to add someone with a Scrum Master role and the others with Participant roles - let's say six participants in this example.

Because the tasks in the Scrum pattern are defined as top-down, even at this stage xProcess is able to provide a project schedule, based on the specified duration of the project. More usefully though, this is the time to create the first Sprint (right-click on the Sprints task and select New...) and then create some Backlog Items, either in the Sprint or in the Unscheduled Backlog if we don't yet know which Sprint we want them to be completed in. Backlog Items are prioritized, firstly from the particular Sprint into which they are created or moved, and secondly by the priority order of the tasks within a Sprint. You can edit this priority order by opening the Sprint editor, clicking on the priorities tab and either dragging and dropping or changing the priority number.

Once you have a Sprint which contains the items the team will be implementing, open the Burndown view. This provides both the history of how much work has been completed so far in the Sprint and a forecast of what should be completed. You'll see immediately for example if there's too much work in there and forecast dates are beyond the end of the Sprint. Here's an example of just one such Sprint... (click on the image to see more detail)Looks like some discussion needs to go on as to whether all the functionality is vital this time round!

Latest patterns for FDD

The release of 2.8 this week sees some interesting updates to the FDD patterns. Like the Scrum updates for xProcess, the new FDD process uses "composite tasks" to define the structure of FDD projects, allowing them to be expanded top down as the details of feature sets and features are defined.

This hierarchy diagram shows the structure of the FDD project pattern. For those familiar with the method, the 5 stage process is visible in the top-level tasks:

1. Develop an Overall Model
2. Build a Features List
3. Plan by Feature and
   
4. combined with 5. Design by Feature - Build by Feature.

Note that the darker blue nodes are patterns, so these can be further expanded in the hierarchy diagram or viewed in the graphical pattern editor.

Here for example is the hierarchy view of the Feature Set pattern, which groups together a set of related features into a deliverable package which can be scheduled for a particular release. Note that here the "Features" composite task, as well as containing Features, may also group Defects (work on correcting issues from previous releases) and Tasks (any other work related to the Feature Set).

The Feature pattern has already been the subject of a number of postings on this blog (see for example...). The pattern diagram shown here uses a quite traditional view of the tasks required to deliver a feature with the emphasis on Specify (the "design by feature" part) and Develop (the "build by feature" part). We can see more detail of this task pattern by using "Go Into" in the pattern editor. Here the specific artifacts and quality gateways that are associated with each task, as well as the number and types of roles required to carry out the task, can be reviewed and modified.
Clearly other ways of breaking these tasks down are possible, and some of the FDD literature (for example Palmer and Felsing's book Feature Driven Development) provide alternative schemes that place stronger emphasis for example on design and code walkthroughs rather than the test-driven approach implied here.

The beauty of xProcess is that the task patterns are all easily and graphically editable so you can make this method match exactly what you want the FDD teams to carry out. As all plans, tasks, artifacts, processes and time records are stored in the xProcess versioned data stores, the compliance with your process can be monitored at any time, either to improve the process patterns where teams have discovered better ways of working, or to improve the teams' approach by following the best practice captured in your process patterns.

FDD has a three-level hierarchy of functionality: Features, Feature Sets and Major Feature Sets (also referred to as Business Areas). So far we've seen where Features and Feature Sets appear within the hierarchy of a project. Major Feature Sets (MFS's) are handled slightly differently. MFS's are created by an xProcess pattern in a similar way to the other patterns we've looked at, but they result in categorized folders rather than tasks which are part of the project hierarchy. This is so that the Feature Sets are visible within the Gantt charts and release schedules. Because of the scope of major Feature Sets, they generally do not have such a clearly delineated start and end date and so it would not make the project schedule clearer to include them in that way. So opening a MFS folder shows you all the feature sets and features in that category. You can then review and prioritize the features in just this one business area. Here's an example of a MFS in a particular project with its corresponding Gantt chart (click on the diagram to see more detail).
Finally in this brief review of xProcess FDD, the pattern for a Release is also instructive. Again a prioritized folder is used for the Release pattern, rather than a task in the project task hierarchy (see the Scrum method for an example of a process that uses this alternative). By default just one release will be created in the project (with a target close to the end of the project). However the Project Manager can create as many additional interim releases as he requires. The "scope" of the release is defined by moving the required features/feature sets/tasks into the release folder. The scheduler of xProcess uses the implied and defined priorities of these tasks to calculate completion dates and provide alerts if targets are unlikely to be met. As the project progresses, the scheduler uses the input from team members completing and possibly re-estimating the required effort for tasks to give immediate visibility of targets' status and costs providing all stakeholders of the FDD projects timely and detailed information to support decision making and further planning.

Set size to match effort

I explained in another entry that size and effort are distinct metrics for tasks. However it's useful to keep the overhead of estimating two closely related items to an absolute minimum. This is why the patterns in the "Simple Process" uses the user's input of a size metric (in "ideal days") to automatically complete the effort estimates (usually displayed in person-hours or person-days). They can be changed subsequently though and if you want to re-synchronize them at some point - say when you a re baselining a plan - a utility for doing so is useful.

Here's a simple Action that you can define in your process (make it a "UI Action" by setting this field to True).

Action Name: Set size to match effort
Expression: setSize(getEffortIncludingChildren()/480.0)
Applicable to: Task
UI Action: True
Parameters: (none)

Having done this you can expand your task hierarchy in the explorer, select the tasks you wish to set size on, and then right-click and select UI Action -> Set size to match effort .

Note: From version 2.9 of xProcess this action is included in the Simple Process.