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!
The Improving Projects blog from Huge IO (UK & Ireland) is primarily about products, organisations and projects... and how to improve them. As well as musings on agile processes, software engineering in general, and methods like Kanban and Scrum, there's advice here too for users of process planning, execution and improvement tools - and the metrics they can provide. https://uk.huge.io
Tuesday, July 31, 2007
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:
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.
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:
- Develop an Overall Model
- Build a Features List
- Plan by Feature and
- combined with 5. Design by Feature - Build by Feature.
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.
Subscribe to:
Posts (Atom)
Breakout sessions that ensure everyone in the meeting meets everyone else
Lockdown finds us doing more and more in online meetings, whether it's business, training, parties or families. It also finds us spendin...
-
Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many su...
-
Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - ...
-
Understanding Cost of Delay (Part 2): Delay Cost and Urgency Profiles In part one of this series of blogs on Understanding Cost of Dela...