New smart use case stereotypes for service oriented architecture

Smart use cases are a great technique for specifying standardized requirements in many types of projects. Over the past few years we have smart use cases being modeled and written in projects using Java and .NET, as you might expect, but also in Sharepoint projects, business intelligence, service oriented projects and even SAP implementations.

Stereotypes drive standardization
Standardization of your requirements can be an important driver to simplify software development and software rejuvination projects. An important addition to the smart use case modeling technique is the use of smart use case stereotypes.

These stereotypes represent often occurring patterns of requirements. Well known our the stereotypes manage, that represents a maintenance use case on some domain object, or search, which helps users to find a particular domain object, guided by search criteria. Other known stereotypes include select, master-detail, view, and report. As you might expect, these stereotypes all deal with user interaction.

Over the years however, we have gathered quite a few stereotypes, also in other fields. We have described for instance stereotypes that deal with Extraction Transformation Load (ETL) processes in data warehousing projects, such as aggregate, calculate and load.

Stereotypes not only help to put focus in modeling workshops, they also facilitate more easy project estimates, and even allow for straightforward code generation and isolated testing. Even better, once you marked the stereotypes (and put them into a UML profile), it will allow you to create much richer use case diagrams, modeling in colour.

Modeling in colour using (profiled) smart use case stereotypes

Slicing service oriented projects
More recently we have applied smart use cases to service oriented projects. These projects tend to be more complex than regular software development projects, and focus around more elaborate architectures Service oriented projects mostly include:

• Flexible front-end features. These can be either web pages, mobile phone front ends, Windows native applications or even Flash or Silverlight applications.
• Process-oriented middleware. Service oriented processes always implement business processes. These business processes or workflows are run in middleware, more specifically in an enterprise service bus (ESB), although having such a bus is not mandatory. There are many vendors supplying busses, such as IBM, SAP, Oracle and Microsoft.
• Stable services. A very important part of service oriented projects consists of the discovery and realization of services. Most often these services are implemented on top of existing legacy or packaged systems.

These slices in service oriented project all serve particular means and responsibilities. The approach to modeling smart use cases in such projects offers quite a few benefits. Next to modeling the front-end use cases, smart use cases help to model the business processes, and discover the required services.

Stereotypes for service oriented projects
In recent projects, that involved such complex service oriented architectures, we have gained a lot of experience in identifying and modeling smart use cases. This week we have analized a number of such models from different projects. This results in a set of new smart use case stereotypes, specifically targeted at the processes that run in middleware, and the encapsulation and execution of services.

One of the smart use case diagrams we’ve investigated

Next to our well-known front end smart use case stereotypes, the new service oriented stereotypes include the following: process, aggregate, dispatch, validate, read, write and inform. I will elaborate on these stereotypes in the next sections.

Stereotype process
A use case of stereotype process executes a business process. In most cases it delegates the execution of services to other use cases, often of types aggregate and dispatch.

The process use case is in the lead, and uses the post-conditions from called use cases to steer the process. This type of smart use cases is generally implemented in the enterprise service bus, such as BizTalk or SAP Xi.

Stereotype aggregate
An aggregate typed smart use cases generally is used to create a single response to a request.

The stereotype is called aggregate as these use cases trigger other smart use cases, othen of types dispatch and read, and aggregates the results from these use cases into a singel response.
Stereotype dispatch

Smart use cases of type dispatch are intended to link the aggregate or process types use cases to services that either require some mapping, or typically run outside the organization.

Mapping is often required, as the available services do not always deliver what is required by the calling use cases. The dipatch smart use cases performs the mapping (hence and forth) and relays the work to the actual service, that is often of type read or write.

Stereotype validate
Executing business processes often include specific validation services, for instance to see if an customer is allowed to add a particular product to their subscription (as in one of the projects we investigated). Smart use cases labeled with the validate stereotypes return a single answer, that can be either a yes or no response, or a single value from a limited list of possible codes.

In cases of more complex validation, for instance when match-making between different back-end or external systems is required, the validate use case relays fetching the required information to dispatch, read or even aggregate smart use cases.

Stereotype read
Smart use cases with the read stereotype are the most basic services. Here one or more domain objects or entities are returned from a back-end system. This often includes compressing a whole hierarchy (such as with many SAP systems), such as a product hierarchy into a single returning message.

Stereotype write
In reverse, write typed smart use cases will pick up such a compressed hierarchy that is input to the use case, distribute the hierarchy into the back-end systems and persist it.

Stereotype inform
During the execution of a business process, the actual user of the whole process (being the actor of the user goal level use case initiating the process) needs to be informed of the status. The actor might get an email, such as in a subscription process to acknowledge successful subscribing, or be sent a letter. Other alternatives are of course also possible.

The inform use case is responsible for merging the text of the message being sent with the actual domain objects the use case model evolves around.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com
www.smartusecase.com

Posted by Sander Hoogendoorn on February 4, 2010

Introducing our agile dashboard

The Accelerated Delivery Platform’s (ADP) Agile Dashboard is a pragmatic and publicly available tool (free) for managing project progress online. The Agile Dashboard was originally intended to manage progress for our agile projects, but these day it is used in a much broader perspective.

As the ADP Core Team receives a lot of questions about it, it’s time to present a small introduction here, including future directions.

Administrating projects
The Agile Dashboard simply administrates projects, project teams, work packages and work items. Furthermore, the Agile Dashboard allows you to define statusses your work items go through. In a typical Scrum project you will likely have ToDo, Working and Done. In a typical Smart project this will likely be New, InIteration, Working, Testing, Rework, Done, Dropped.

Managing work items
Work items such as user storie or features can either be added manually, or via a straightforward import feature that allows UML models to be imported in the Dashboard (from XMI). As Smart projects evolve around implemeting smart use cases, use cases can be marked as work items automatically. For each work item the complexity of the item needs to be established. Whem importing a UML model using smart use case stereotypes, establishing complexity is automatically handled.

The actual Dashboard
The main page in the Dashboard shows the progress of your project’s work items, or a the work items in a single work package, as shown below. This page will give you an immediate overview of the project.

When a work item changes status, e.g. when development is done, the user can drag-and-drop the work item to te next status, in this case for instance Testing. This pop-ups a next page where the user can add comments, and give an estimate for the amount of work still needed on the work item. Note that this is typically an action that is done during stand-up meetings.

Real-time burn-down
This information is used by the Agile Dashboard to recalculate the burn-down chart for the project real-time.

The freely available Agile Dashboard offers very basic functionality and does not excel in abundant charting and progress reporting. This is done to make managing progress in projects as easy as possible – albeit the Dashboard could do with some minor useability improvements.

Using the Agile Dashboard thus presents real-time project progress. It’s online availibility makes it suitable for distributed scenarios, e.g. in offshore – we e.g. manage projects with it that are executed on several locations simultaneuously in the Netherlands and India.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

P.S. There's an additional part to this post on my personal blog, that elaborates on the new features of the dashboard, to be implemented as soon as possible. Check it out at: Introducing our agile dashboard.

Posted by Sander Hoogendoorn on January 23, 2010

Beyond agile testing. Or: how to become a pro-active tester

Agile – in all it’s variations – becomes an increasingly popular process for realizing software. The roles testers and testing plays in these projects is challenging and new. Testers are no longer considered code-killers, but can play – and are expected to play – a very pro-active role in agile projects.

Although all agile process agree on the importance of testing, unfortunately many of these agile processes do not elaborate much on the specific role testers have. Testing is often referred to in unit testing, which is really a developer technique. Much less attention is given to true functional testing, performance testing, integration testing and acceptance.

Tester and developer closely collaborating

To investigate where testing and testers can play this vital new role you will need to see what it means for projects to be agile – beyond the scope of the processes available, such as XP, Scrum, Lean, Kanban and Smart. It’s about close collaboration of all different roles, finding the right unit of work (that also needs to be testable), defining short iterations, celebrating feedback and delivering fast and early.
Testing from day one

When introducting agile and testing to each orter, in short a number of questions pop up:

• What is this agile stuff anyway? To traditionally organized projects and organizations it is not self-explinatory that testing and testers will be in the project from day one.
• How does an (a)typical agile team look like? Many agile processs do not include the roles of testers, but rather stick to the traditional agile Bermuda triangle of coach-customer-developer.
• What can be the role of testers in agile projects? In my personal experience, that comes from doing projects in all kinds of processes, testers do play a vital role in almost all activities in a project. Testers can influence projects positively during software estimation (test effort is always underestimated), requirements gathering (what scenarios apply to a use case?), (test) design, and even development in agile projects. There are very good reasons for have an explicit test role in agile projects, as the somewhat more structured agile process such as Smart and DSDM emphasize.
• What’s a good unit of work in agile project when it comes to functional testing? Do we apply user stories, features or smart use cases? In my opinion, adding some structure is not too bad, especially when it comes to larger, more complicated projects such as service oriented or cloud oriented projects. User stories will be a to adhoc techniques to deal with in such projects. Features, but especially smart use cases add this little bit of structure and reuse that make life easier.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

P.S. There's an additional part to this post on my personal blog, that elaborates on a new talk I created to this subject, aimed at introduction agile to testers, and agile testing to (agile) project managers and project teams. Check it out at: Beyond agile testing

Posted by Sander Hoogendoorn on January 8, 2010

Questions on smart use cases. Part II - The smart use case life cycle

As you might have heard from me before (endlessly), smart use cases are a fairly straightforward reqirements technique that we have introduced in many different types of projects, such as Java, .NET, BI projects apply smart use cases, but also in service oriented projects, where smart use cases where used to model the front end and also the services and workflow.

At times I receive question on smart use cases in projects, this time from Belgium, by Erwin Bauwens. See Erwin’s original Dutch version below.

Erwin: In the smart use case life cycle all smart use cases go through the same stages (“New”, “In iteration”, “Working”, “Testing”, “Rework”, “Accepted”) from left to right. But, I take it, from “Rework” use cases go back to “Testing”?

And, additionally: it’s only the sub-function level use cases (or the user-goal level use cases without sub-function level use cases) that go through the cycle.

The smart use case life cycle identifies a number of stages smart use cases CAN go through. The stages proposed in Smart (the agile methodology the life cycle comes from) are not mandatory, but represent the most used stages. Some projects add stages such as “Design”, or split “Testing” into “Testing Team” and “Testing Customer”.

Having this simple staged smart use case life cycle allows projects to put up an nice dashboard – either on the wall or white board, or online using a dashboarding tool such as our Agile Dashboard, Mingle or VersionOne.

Example smart use case dashboard

In fact, ALL smart use cases go through this life cycle, not just the sub-function level ones or the user-goal level ones without additional sub-function level use cases. And indeed, coming from “Rework”, it is likely that the use case needs to go through “Testing” again.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on December 17, 2009

Use SCRUM to capitalize on naturally Agile teams

Every proposal is a unique piece of Agile work

In companies like ours, Agile is not always easy to put in place. As we have strong contractual commitments with our clients, we need to define the clearest plan beforehand so that we can ensure that there are benefits on both sides before doing a project. That said, we already use Agile with many of our clients, even though most of our projects still use more “traditional” methodologies.

However, there is an area in which we are fundamentally Agile without even thinking about it: the response to a request for proposal. Indeed, we have many different competencies at Capgemini, but we also have different schedules, time scales, clients and cultures that we need to mix in order to build the best answer to our clients’ needs. Usually, the team builds itself up from the business and/or technical leaders’ networks. A lot of people get involved and it is often hard to define the scope that everyone should look at and agility can sometimes become chaos.

SCRUM for dummies (skip this part if you are already SCRUM literate)

In a nutshell, SCRUM is a project management process that has been designed to help teams to become Agile. It has been conceived with simplicity in mind so that it is easily accessible and anyone can get its purpose within just 15 minutes. There are only three concepts to grasp with three items each.

SCRUM has three roles:

• The facilitator is called the SCRUM master; he is the project manager and helps the team in delivering value to a product owner.
• The product owner is in charge of defining the scope of a project and prioritizing the features for the team to work on.
• The team represents every person working on the delivery of a project.

SCRUM has three deliverables:

• The product backlog is a prioritized list of features to be implemented. It is the heart of the process. The goal of SCRUM is to optimize the capacity of a team to deliver the items of this list.
• This list can be broken down in a sprint backlog which describes all the tasks to be done during an iteration. These tasks are a detailed breakdown of the features that have been identified as the highest priorities in the product backlog.
• The burndown chart tracks the progress of the team during an iteration (also called sprint). The SCRUM master can easily check the velocity of the team from the burndown chart.

SCRUM has three ceremonies

• The daily stand up happens every day and every member of the team has to tell the team what he did the day before, what he will do during the day and to describe any blocker he might have. This meeting is usually held in the morning and everybody stands up so that the meeting doesn’t last long (15 minutes max.).
• The sprint planning happens at the beginning of each sprint. The team breaks down each item of the product backlog into tasks until there is not enough bandwidth in the team to add a new item from the list.
• The retrospective happens at the end of each sprint. It gives a chance to the team to analyse how the sprint went. It identifies the good parts and the bad parts and proposes enhancements for the following sprint. It provides a simple framework for continuous improvements.

Applying SCRUM to proposals to structure Agile.

At Capgemini, we already have detailed guidelines for proposals which describe all the items a team has to provide to meet the quality expectations of our group. Therefore, our product backlog is nothing but this existing list. The product owner is obviously the client who requested the proposal. If some of the points in the request are unclear, the team will ask the client for details and prioritisation. The SCRUM master is either a project manager involved in the team or the business/technical leader described in the introduction. Project managers tend to have the right skill set to facilitate meetings and define good KPIs but it is not mandatory to have one involved.

There are three levels of maturity a team can go through to improve the proposal.

1. The lowest level involves only the product backlog and the daily stand up. Having everyone committing to a piece of work everyday and reporting on problems solve a lot of issues which usually pop out only at the very end of the process. Using these parts of the process facilitates the day-to-day work.
2. The second level involves a sprint planning and a sprint backlog. By increasing the visibility on the tasks, the bottlenecks are identified very early in the process. The day to day work is also easier to track as the sprint burndown gives an obvious status of the remaining effort. This level focuses on optimization.
3. The third level involves all the SCRUM elements, especially the retrospective. By identifying what went well and what did not go so well, it provides a handful of actions to speed up the following responses and also to increase the quality. Using all the aspects of SCRUM improves capitalization.

Of course, the bigger the subject is, the higher the maturity level should be.

At the moment, the usage of SCRUM for the responses is still experimental; however, the few experiments gave encouraging results and people from different cultures and even different companies (as partners got involved) worked seamlessly together. This type of initiative can be applied to a lot of situations where agility is natural but where you want to go from a process that just work to a process that continuously increases efficiency and enables capitalization. Moreover, supported by web 2.0 technologies like google docs or yammer, the work can be even smoother, but this will be the subject of another post…

Pierre Boissonnet is a programme management consultant at Capgemini based in Lyon. You can follow and connect with him via Twitter or Delicious

Posted by Pierre Boissonnet on November 19, 2009

Are user stories an alternative to (smart) use cases?

About a week ago, someone (from the UK) send me an email with the following question:

I like your article on Smart Use Cases. Before I throw my hat in the ring on this, could you tell me your feelings on User Stories as an alternative to Use Cases?

To be quite honest, I’m not much in favor of using user stories. In my honest opinion, user stories are too unstructured to serve as a good unit of work in larger projects – although some projects actually benefit from having unstructured requirements. However, in my opinion regular use cases are unsuited to, as they differ too much in both complexity and granularity. For example, I have seen projects where implementing a single use case took several months. Not really handy in projects that are based on two week iterations, such as the agile projects we run.

We have therefore proposed our smart use cases – and have been using them for the last ten years, with ever growing success. Smart use cases are smaller, equally granular and more structured, but do not require much more elaboration than user stories. When it comes to larger projects, including for instance business intelligence and service oriented projects, smart use cases much better reflect the mapping from business processes and workflows to software development.

Furthermore, to work on user stories in iterations in agile projects (or sprints if you prefer), the user stories are broken down into tasks. Unfortunately, since user stories can be very different in nature, so are the tasks. When we use smart use cases, the tasks are always similar, that is, we design, test design, build (and quite often generate), test, rework, accept or drop them. In most projects in an almost daily cycle (the Smart product cycle). The agile dashboard in our projects actually reflect these solid tasks, which makes planning them easier.

Another argument for preferring smart use cases over user stories, is that they can be estimated on an abstract scale rather than in hours. Important is that this estimation process is repeatable, and can be done by anyone (of course with some knowledge).

Over the years we have created a rich vocabulary of smart use case types, including types for maintenance, reporting, services, BI and file exchange. Applying this vocabulary (in stereotypes) allows for fast but structured requirements modeling.

Some links can help you further investigating this material:

• Smart use cases versus regular use cases. http://www.accelerateddeliveryplatform.com/SmartUseCase
• The agile Smart process. http://www.accelerateddeliveryplatform.com/SmartLifecycle
• Estimating smart use cases. http://www.accelerateddeliveryplatform.com/SmartEstimation
• Smart product life cycle. http://www.accelerateddeliveryplatform.com/SmartUseCaseCycle
• Smart use case stereotypes. http://www.accelerateddeliveryplatform.com/stereotypes

Love to hear your feedback and opinions.

Sander Hoogendoorn
Principal Technology Officer NL
twitter.com/aahoogendoorn

Posted by Sander Hoogendoorn on June 28, 2009

Delivering products in agile (Smart) projects

In most cases where a form of agile software development is applied, projects are challenged with difficult issues, such as a swaggering scope, unclear and incomplete requirements, unstable software architecture, are quickly approaching dead lines. Within these strict boundaries projects try to deliver high quality software at high productivity - or velocity. This is not an easy challenge.

Delivering just what is needed
Therefore, during agile projects there is high pressure on delivering just that what is needed. The emphasis of an agile project team is on creating just the right (amount of) software, and minimizing the amount of work spent on other products, such as documentation and work in the peripherals of the project. Although many project teams seem to call on this principle to actually not deliver any documentation, the fine art of being agile is delivering just-enough, just-right documentation.

In our experience, a lot of time is spent in agile projects on deciding what's enough, and moreover, what's right. Especially when projects are executed in complex organizations, and applying complex (service or cloud oriented) technology, finding the right level of documentation is actually a quite intriguing task, and goes beyond writing (structured or not) user stories.

Delivering products
In the vision of the agile process Smart (and other agile processes, including Scrum and feature driven development) projects should focus on delivering products, not just on performing activities. Please note that working software is not the only product a project delivers.

The agile process Smart suggests to deliver a number of products that will guide projects through these just-enough, just-right in a more standardized fashion. In essence, Smart projects are product driven, as are other agile processes such as Scrum, FDD and OpenUP. During each of the iterations in a Smart project, the team delivers a number of working products. These products fall into a few categories:

• Project deliverables. In each of the different types of iterations Smart suggests to deliver additional products that will help drive your project to success. These products might include well know deliverables such as a project proposal and non-functional requirements. Although none of these product are actually mandatory in a Smart project, they are considered good practice, and over the years have been produced in numerous Smart projects. Using these standard suggested products, organizations get an even better grip on the projects at hand. Note that emphasizing the existence of other project deliverables besides working software (in smart use cases) does not mean projects become less agile.
• Smart use cases. The body of products delivered in a project is formed by smart use cases, small discrete pieces of functionality that drive development. Smart use cases is a technique to rapidly model your functional requirements at a equal-granular level. Smart use case supply a small and very useful unit of work, and furthermore serve as the main unit of estimation, planning, but also drive realization, testing and even delivery.

All products, both project deliverables and smart use cases run through (a subset of) the product life cycle.

Project deliverables
All products that need to be delivered to run your projects and do not deal with implementing functionality directly (which moreover is partitioned in smart use cases) are referred to as project deliverables. Most of these project deliverables are one-off, although they might be maintained and updated during the project, such as the project's software architecture and the domain model. Any Smart project needs to decide which of the suggested project deliverables will be produced, and in which iterations.

An easy way to achieve the optimal set of project deliverables is to add the products suggested by Smart to the project's backlog during the different iterations defined in the Smart process. Or alternatively, add them to the backlog at the start of the project. This allows project teams to add them to the list of products to deliver in any of the iterations.

For example, during the first Propose iteration the smart use case model, a project estimate and a project proposal can be added to the iteration backlog. At the start of the Scope iteration, the software architecture and reusable services might be added. At the start of each of the iterations, the customer and the project team decide which of these products will be picked up and produced.

Examples of project deliverables
Some examples of project deliverables are:

• Project proposal. A first proposal covering the primary scope of the project and a first cut estimate is produced as a the final project deliverable for Propose iterations.
• Project plan. The project plan describes the project approach, the stakeholders and goals, business case, risks, resources, timelines and project estimate. The project plan is mostly delivered at the end of Scope iterations.
• Iteration plan. For each iteration a very brief iteration plan might be documented, sometimes not longer than a single page. This iteration plan describes the list of products (mostly smart use cases) to be implemented and resources needed. In most projects, iteration plans result from the planning session at the start of each iteration.
• Software architecture. Document describing the architecture for the project. Ideally, your software architecture is an instance of a reusable reference architecture that might be in place at a organization. Having a reference architecture will allow a project team to focus only on deviations. This saves valuable time and effort.
• Business process model. Most projects implement one or more business processes, and a number of additional functions that support these processes. Smart use cases can be derived from these business processes, independent of how these processes are modeled. The business process model is either obtained from the organization, or created during the project.
• Smart use case model. The smart use case model is leading in Smart project. It delivers software estimates, and presents an overview of the scope of the project.
• Domain model. Most custom software development projects will have a model describing the business domain and business services. Sometimes this model stems from previous version of the software, for instance modeled in a data model. In service oriented projects, the domain model in most cases overlays the services called in different back end systems, as forms the basis for a service consuming front end.

Again, in most cases these deliverables are one-off. They are created once during a project, but quite often maintained or updated later on, think of the domain model and a reusable services model.

Smart use cases
Most of the work in delivering working software in iterations that are of type Realize or 'Finalize'' relates to the realization of smart use cases. The smart use case has become our main unit of work. They are implemented following the product life cycle. The work on each individual smart use case includes analysis, design, test design, build, test and acceptance. This work is always visualized using an agile dashboard, either using post-its on a wall, or using an (online) automated dashboard.

Sander Hoogendoorn
Agile evangelist

Read more
You will find more information on these subjects at: www.accelerateddeliveryplatform and www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on May 11, 2009

The iteration cycle of an agile Smart project

Smart is an easy to implement agile process, that is essentially smart use cases driven. Although Smart mixes very well with other agile processes and techniques, such as Scrum, XP and FDD, the process that takes a project through a little more ceremony than you might expect from a number of other agile processes. For instance, Smart suggests a number of products to add to the backlog, that deal with managing the project environment, such as project plans, estimates, or even setting up the development environment. Moreover, Smart is based on the use of smart use cases, where Scrum and XP on less standardized and less structured (user) stories.

The Smart iteration cycle
Each type of iteration in a Smart project is concerned with delivering a (number of) product(s), not necessarily all code. During early iterations, suggested products could for instance deal with setting up the project, determining the scope, creating a project estimate, or something trivial such as creating a straightforward project plan.

Further down the road, most of the products delivered in iterations will be (designed, built, and tested) accepted use cases. Depending on the type of products to be delivered, the iterations are branded as Propose, Scope, Realize, Finalize, and when the software is put into application maintenance iterations are usually typed as Manage.

There is one thing all these types of iteration have in common. All iterations in a Smart project follow the same procedure. This procedure is called the smart iteration cycle. The smart iteration cycle is split up into three different parts. These three parts in an iteration are known as Plan, Build and Evaluate.

Plan
Planning your iterations is essential. During the iteration kick-off the customer and the project team decide on which products will be delivered during the upcoming iteration. How many products can actually be delivered depend on the team velocity and the estimated effort that is required to realize the individual products.

A small but pragmatic iteration plan is usually set up, which also defines the acceptance criteria for each of the products to deliver - in other word defining done for each of the products.

Smart projects focus on implementing smart use cases ,delivering working software. One of the main reasons for applying these is that the approach to modeling smart use cases is standardized an thus it is easier to define done. Furthermore, it is also easier to estimate the effort required to realize these (quite often stereotyped) smart use cases.

Build
During the Build part of any iteration, the products will be realized to meet with the done criteria. To be able to monitor a project’s progress we realize products following a simple product life cycle, which is easy to visualize in a project dashboard. Although there are several possible variations of this product life cycle, it is always executed on a daily basis, starting with define what still needs to be done to finalize the product during the daily stand-up meeting.

When it comes to implementing smart use cases, the product life cycle defines brief analysis, design, coding, test and accepting the planned smart use cases. This is in high accordance with YAGNI principles, as elaboration of the individual smart use cases takes as little time as possible before a particular use case is actually built and tested.

Evaluate
Each iteration is rounded up and evaluated. This is quite an important moment in the iteration. Basically we evaluate the speed at which the project is travelling, the products that are delivered and how well the process that is applied suits the project.

Measuring in abstract points, it is quite easy to evaluate the current speed of a project, given the number of iteration spent and the number of points realized. This results in the iteration velocity, the average number of points realized during one iteration. Projecting the iteration velocity on the number of points still left in the project, will present you with an estimated end date. This data is used the steer the project.

Each of the products delivered is briefly considered during evaluation. The project’s progress can often easily be demonstrated with a short demo.

Although Smart projects are highly standardized, we see that it must fit in with the customer organization, or can be optimized to deliver a more precise to what is actually needed, or work even more efficiently. During evaluation adjustment to the process are discussed, and will be implemented during the upcoming iteration.

Sander Hoogendoorn
See for more information (and images): www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on April 22, 2009