Best Practices for Prototyping in Software Development - 4

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the fourth in series of articles on Prototyping in Software Development.

Who should be involved, how far you should go and when do you have to do Prototyping in a Software Development Project?

Often Prototyping in Software Development Projects will be done without planning and without involving the relevant stakeholders. This will lead to wrong expectations, initial budget overruns and customer satisfaction issues.

1. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

Treat this phase with importance, just like any other phase in SDLC and try identifying and involving the relevant stakeholders at all stages in the prototyping stage.

2. When Do You Build a Prototype?
Depending on the scope of the prototype and the level of detail required, prototypes can be built at any time during the project. Most often they are created early in the project, during the planning and specification phase, before developers write any production code. That’s when the need for exploration is greatest, and when the time investment needed is most viable. If developers instead of program managers or designers are prototyping, scheduling time becomes even more important because you need to make sure the work invested in the prototype is accounted for in the development schedule. Planning for any UI release should include some level of prototyping.

Late in a project, smaller prototypes can help resolve tough design and technical issues. A quick HTML mock-up of how a dialog box or Web page should behave can help answer a developer’s question or give other teammates a feel for what the desired experience should be. In some cases, a strong program manager or designer can implement the behavior in Microsoft JScript development software and approximate much of the programming logic that developers will need to think through.

The time it takes to create a prototype can vary tremendously, depending on the scope and precision of what the end result needs to look like. An informal prototype could mean a few hours of work by one person; a more organized effort can involve weeks of effort by an entire team.

3. How Far Should You Go?
In your prototype, build only as much of the design as you need. It’s okay to have buttons that don’t work, or text that never updates. As long as you can experience the interactions you want to explore, it’s fine to use smoke and mirrors for the rest.

Here are a few reasons why you should focus your efforts carefully:

3.1 Cost of building the prototype.
You want to minimize the cost involved in building the prototype. The challenge with prototyping is recognizing the minimal investment needed to effectively answer your questions about the design. This is where usability studies are critical, because they clearly identify the parts of your UI that need the most work. Even without usability studies, you should clearly define what user problems you’re trying to solve, or what tasks you’re trying to improve, with the design in your prototype.

3.2 Limited lifetime.
Prototypes should have clearly defined lifetimes. Is the end goal a presentation at a team meeting? An executive review meeting? A spec review? A usability study? Convincing yourself, with your devil’s advocate hat on, that the design solves a user problem? Once the needs for these specific objectives are met, the prototype should be set aside. The basic mindset is that the code or bitmaps generated in a prototype will be left behind in most of the cases. There might be exceptions where code or visuals live on in the product, but the expectation should be that this won’t be the case.

3.3 Risk of overwhelming the team and setting wrong expectations.
Showing prototypes to developers and teammates can be tricky. An overly complex or elaborate prototype, with amazing visuals and animation, can overwhelm people. You should always have a sense for how far to go and how much of what you’re creating in the prototype you want to be taken seriously.  This is important because to build this amazing visuals with full functionality will be a challenge and will take more effort.

So the general practice that is preferable to follow is to involve people who can later be part of the design and development team, try writing code and scripts during prototype phase in a language that can be easily merged and scaled to the actual language and projects that you use as part of the subsequent phases in your projects.

Best Practices for Prototyping in Software Development - 3

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the third in series of articles on Prototyping in Software Development.

Tips and Techniques in User Interface Prototyping during Software Development

The following tips and techniques should prove valuable during the prototyping phase of your SDLC (Software Development Life cycle), these can also be used as guidelines, best processes and practices for User Interface Development:

Consistency: Most important thing you can possibly do is ensure your user interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs.

Set standards and stick to them: The only way you can ensure consistency within your application is to set user interface design standards, and then stick to them. Preferably since Prototyping is done in an Agile manner, you should follow Agile Modeling Standards in all aspects of software development, including user interface design.

Be prepared to hold the line: When you are developing the user interface for your system you will discover that your stakeholders often have some unusual ideas as to how the user interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them.

Explain the rules: Your end users and business users need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step.

Screen Navigation:

Navigation between major user interface items is important. If it is difficult to get from one screen to another, then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams should optionally be developed to further your understanding of the flow of your user interface.

Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when designing a user interface for people from this culture? You want to organize navigation between widgets on your screen in a manner users will find familiar to them.

Word your messages and labels effectively: The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing “You have input the wrong information” or “An account number should be eight digits in length.”

Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input” and “An account number should be input” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The account number must be input” to make the two messages consistent.

Understand the UI widgets: You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines your organization has adopted.

Look at other applications with a grain of salt. Unless you know another application has been verified to follow the user interface-standards and guidelines of your organization, don’t assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good user interface design and bad user interface design, you must be careful. Too many developers make the mistake of imitating the user interface of poorly designed software.

Use color and styles appropriately: Color and styles should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application.

Align fields effectively: When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.

Expect your users to make mistakes: How many times have you accidentally deleted some text in one of your files or in the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your user interface to recover from mistakes made by your users.

Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings.

Your design should be intuit able: In other words, if your users don’t know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your users can readily understand and ideally learn.

Don’t create busy user interfaces: Crowded screens are difficult to understand and, hence, are difficult to use. Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing.

Take an evolutionary approach. Techniques such as user interface prototyping and Agile Model Driven Development (AMDD) are critical to your success as a UI developer.

Best Practices for Prototyping in Software Development - 2

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the second in series of articles on Prototyping in Software Development.

Tools and Technologies that can be used in Usability Engineering, prototyping during Software Development

There are several different tools and technologies you can use for creating prototypes, each of which has its advantages and disadvantages. Consider the type of design work you’re trying to prototype and the goals of your prototyping effort as you decide which tool or technology is right for you.

Paper - For usability studies or quick reviews, paper is often the fastest way to prototype a design idea. Using Photoshop, mspaint, or any tool you are comfortable with, produce screens that express the design, and print them out on paper. If you make enough screens, you can simulate walkthroughs, allowing test users to make choices and experience the design. However, for prototypes of moderate complexity, generating paper prototypes can be cumbersome. Highly interactive things like games or chat rooms can not be simulated well on paper. Also, the more elaborate the tasks, the more pages you might need to have handy.

Microsoft .NET: This is the fastest technology for creating Windows-style and Web based UI prototypes. The Web browser object makes it easy to integrate HTML UI with your standard Windows-style components. While it’s true that an experienced C/C++ developer might be able to generate UI faster in C/C++, this creates the temptation to reuse code from the UI prototype in your production code. It takes discipline to recognize that the goals of a quick and dirty UI prototype are highly divergent from high-quality engineering. Make sure you know what kind of code you’re writing, and that your team or manager understands what will be discarded.

Macromedia Director or Flash: This is one of the most popular UI prototyping tools among designers. It is most useful for multimedia or non-standard GUI designs, or for prototypes that require significant animation. It’s high flexibility makes it cumbersome for Windows-style UI compared to Visual Basic. However, a proficient Director user can generate Windows or Web UI without difficultly.

HTML: Dream weaver, FrontPage and other HTML editors allow for fast creation of simple prototypes. The latest technologies based on LAMP tools can also be used for faster turnaround times during the prototyping phase. To express an idea, you can often create bitmaps that illustrate a sequence of user interaction, and place them into FrontPage. Then you can create link areas to connect the pages, and simulate how you can interact with the design. Java Script and DHTML take things to another level, allowing for very sophisticated logic and interaction. If you are using HTML to prototype your Web site, the warning just described for C/C++ applies here as well don’t fall into the trap of confusing quick prototype code with production-quality engineering.

Ajax - This is the latest technology that uses Web 2.0 concepts to create user friendly presentation Layers, with this you can break up the page/screen into a variety of small UI elements, like a header, a navigation menu, a sidebar, etc and then we should be able to create reusable snippets of code

Also, most importantly by using Ajax in prototyping, you are prepping up the site for web Application Integration. The general structure of an Ajax prototype is remarkably similar to the structure to how a Engineer would incorporate the design into a web Application framework. They don’t have to dig through endless lines of presentation code, rather each function is nicely separated into it’s own HTML file.

Best Practices in Prototyping in Software Development - 1

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article addresses the needs of prototyping in Software Development , this will be the first part in the series of articles on Prototyping in Software Development.

1. Why Prototype?
Prototyping is a means of exploring ideas before you invest in them. The best reason to prototype is to save time and resources. So, for a minimal investment, you can find usability and design problems and adjust your UI before you invest heavily in the final design and technologies.

On examining the needs of your particular project, you might come up with reasons for creating a prototype other than saving money. Is the goal to explore a new interface model? Make modifications to one part of the existing design? Investigate a new technology? It’s important to be clear about why you’re building what you’re building before you start. If you begin with clear goals, you can be direct and effective in your efforts. The reasons for creating prototypes fall into three basic categories:

1.1 Proof of concept.
Among some teams there are disagreements about the future direction of a project. You can use a prototype to prove that an idea or new approach has merit or value. A prototype can help illustrate that an idea works, express its qualities in a visual and interactive way, and/or motivate team members to think about the problem from another perspective.

1.2 Design exploration.
If you design interactive things, the only way to explore how something will be used is to create a mock-up and interact with it. Sometimes the mock-up is tied to a usability study, where parts of the prototype can be evaluated in a structured way. Sometimes it’s just a way to clearly express to a developer how something should work or look. In many cases, a designer might simply be experimenting, in an effort to get a sense for what approach might work. Anyone on the team can use prototypes to explore design issues, although designers are generally the most skilled. Design explorations should be directed at trying to solve specific problems that you’ve recognized in your product.

1.3 Technical exploration.
Developers investigating implementation approaches to a problem often try out different coding techniques to see if they work well. Using HTML, Jscript, SQL, DHTML, FLASH, ACTION Script, PHP or specific coding approaches within each technology have different tradeoffs. Sometimes a prototype represents an exploration into what technology will work well to support a certain UI or web feature.

Sometimes prototypes are created for a combination of these reasons. If a team plans well enough, they can allot time for a developer and a designer or project manager to work together on a prototype. In such cases, it’s extremely important to clearly define the goals and the contributions each team member is expected to make. You want everyone to be clear on what the goals are, what’s at stake, and what the potential outcome will be.

2. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

Best Practices and Guidelines for Process Tailoring in Software Development

Posted by Ravindra under Software Development Processes

Best Practices and Guidelines for Process Tailoring in Offshore Software Development

What is Tailoring in Software Development?
Tailoring in Software development is the process of extracting a set of processes, tasks and artifacts from the organizations established processes, tasks and artifacts so as to best suit a project to achieve its objectives.

Practices and Guidelines

It is very important that we have a set of tailoring guidelines that will guide the development teams to let them decide what is best for the projects. The guidelines must also specify is that what is Tailorable and what is mandatory. For example in a software development project if a project manager says that the project need not maintain a project management plan then it should be not acceptable as per the tailoring guidelines. So basically there will be some processes, tasks and artifacts that will have to be developed and maintained in a software development project.

So these guidelines must take into account multiple aspects before being released as part of the organization quality management system. These aspects must look into the current state of process implementation, customer’s needs and objectives, project characteristics etc.

Organizations that are offerings services for different types of projects like Full life cycle development, maintenance, QA, Technical support must also look into coming up with life cycle models for each of these type of software projects. These life cycle models must go hand in hand with the Process tailoring guidelines established at the organization level.

The following steps can be considered as some important points that can help in coming up with the tailoring tasks at the project level.

STEPS AT PROJECT LEVEL
Identify Project Characteristics
Identify the characteristics of your software project. These characteristics will be useful in formulating a project strategy and in tailoring processes.

Formulate a Project Strategy
Based on the characteristics of your project, formulate a strategy by referring to Process tailoring guidelines that are established at the organization level.

Select a suitable Quality Management System (QMS) process
In QMS, processes must be defined for the different types of projects; example
· Development (Agile, Maintenance, Waterfall etc.)
· Maintenance projects
· QA Projects
· Technical Support Projects

The tailoring guidelines for project management and configuration management must be made applicable to all projects.

Select lifecycle model for the Software development project and tailor process element accordingly. For each process element, you can decide to do one of the following:

· Implement the process element as per guidelines
· Waive the process element
· Replace the process element
· Add a new process element

Waivers and replacements from the tailoring guidelines and new process elements not defined in the tailoring guidelines should be highlighted in Project Management Plan as Deviations and appropriate process must be followed in getting approvals for the waivers and deviations.

In my next article I will highlight the use of collaboration tools like Project Server and SharePoint and demonstrate how we can use simple features to come up with an effective way of performing process tailoring for software development projects. This will also address the fulfilling of GP 3.1 in CMMi Ver. 1.2 – Establishing projects defined process. We will understand more about Projects Defined process.  

How to customize an existing process template in TFS?

Posted by S Singh under Software Development Practices

In my last post “Process Implementation and TFS(Team Foundation Server)- Part1” I spoke about editing the process template using TFS process template manager. The limitation with this approach is that it commits the changes at the template level which can only be seen in the new project. So, in other words the existing projects using that template would not see the changes.

 This leaves us with the question – how do we customize our process templates to see the changes in the existing projects. Here is a step by step guide to do this:

 Problem:

 Scenario: Suppose I have a team project named “test” which is using TFS-CMMI process improvement template. Due to my current project needs I need to modify the work item Type-“issue” to support an additional state “Awaiting business feedback”-this is to clearly identify all the items that are waiting for customer’s feedback before closure.

The flow would be something like this:

Existing flow:

Propose->Active->Resolved-> closed 

New Flow:

Propose->Active->Resolved-> Awaiting Business feedback->closed 

Solution:

This can be achieved in two ways: 

• Command line Route: Microsoft has provided some command line tools to help with this process. Using witexport you can export a single work item definition file for a specific team project, modify it, and then use witimport to import the modified work item definition into the process template.         

            Step 1:

Make sure the path for the above two command line utilities is in your system environment variable. Otherwise you will have to traverse to the following location to execute these commands: <drive >\Program Files\Visual Studio8\Common7\IDE

Step 2:

Open command line screen and execute the following command: 

witexport [/f Workitem export path/Name] /t [TFS Server] /p [teamproject] /n [workitem name] 

In my case it will be: witexport /f c:\\ ProcessTemplates\issue.xml /t silpunappdev6 /p test /n Issue

Step 3: 

Open Issue.xml in Visual Studio 2008/2005 with TFS process template editor. It will automatically create an issue.wit in “c:\processTemplates”. WIT extension stands for work item type. This is how the file will look like once opened in Visual studio 2008.

Step 4:

To achieve the required customization. I will have to add a new State-“Awaiting customer Feedback” and three new transitions: a) Resolved to Awaiting customer feedback b) Awaiting customer feedback to Closed c) Awaiting customer feedback to Active (In case of rework) Please refer to my earlier post “Process Implementation and TFS(Team Foundation Server)- Part1” for more details about “State and Transitions”.

• Add a new State-“Awaiting Customer feedback” by dragging and dropping the state object from left tool bar on the Workflow tab of issue.wit
• Rename the state to “Awaiting Customer feedback” by double clicking on state object. Please refer to the following figure: 

Add Transitions:

• • Select Transition link on the left tool bar and create a link between resolved and awaiting customer feedback state objects by clicking on them. 

Transition Details: 

1. Resolved ->Awaiting Customer feedback. Please refer to the following figures:
   • Double click on transition object and add a reason for this transition as “Customer Approval Required”. Refer to the following figure(s):

Create the remaining transitions and save the changes. The final workflow screen will look like this:

 

 

 

The author is a seasoned project manager at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

 

Step 5:

After making all the changes to the work item type. Import the issue.xml using the following command line utility. 

Witimport /f [filename] /t [tfs Server] /p [teamproject]  

In my case: Witimport /f c:\\ProcessTemplates\\issue.xml /t silpunappdev6 /p test 

This was the last step required to implement the customization. No you should be able to create an issue with “Awaiting customer feedback” state in your existing ‘test’ project.

In the beginning I mentioned that there are two ways to do this. Actually if we look at it the real difference between the two approaches is in the way we export and import the workitem type xml file. One is using the Command line utility (witexport and witimport) the other approach is through visual studio IDE. Please refer to the snapshot below. The WIT editing part is the same in both the cases. 

 

  About the Author

The author is a seasoned project manager at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

Process Implementation and TFS(Team Foundation Server)- Part1

Posted by S Singh under Software Development Practices

I am going to focus this post to explore the process implementation capabilities and features of TFS. Let me start by sharing my understanding of a Process and then see how TFS can help me implement it.

Process to me sounds like a set of rules/ guidelines that we define to seamlessly implement and integrate various lifecycle stages of our projects. This in turn brings maturity and   discipline to the whole software development practice. It also provides us with some meaningful data to identify the improvement opportunities

Let us consider a Scenario: 

Let’s say I have defined a process based on my projects’ characteristics.  By defining the process I mean the following:

•  Define the project life cycle and phases (Analysis, Coding and Unit Testing, Testing , Bug Fixing)
•  Define types of work items and their attributes (Enhancements, issues, bugs, change requests)
•  Define the work break down structure 
•  Define the workflow(Ex: Creation->Analysis ->coding ->Testing-> bug fixing-> closure)

 Now how can I implement this using TFS?

 TFS Approach: 

• We start with creating the project in TFS by choosing the right process template. By default TFS ships with two process templates:
  • MSF for Agile process template( In general, Use this template if your project is of short duration with quick release cycles and does not rely on any documented/formal processes or any compliance to processes standards are not mandated)            

  • MSF for CMMI Process Improvement template ( This template is more useful if your project is of long duration with predictable/defined release cycles and does rely on documented/formal processes Compliance to processes standards are mandatory.)   

 The template choices are not restricted to the above two. There are several other process templates available online that can be downloaded and integrated with the TFS. You can also create your own template or modify the existing ones using TFS process template editor . We will be looking into it in more detail later.  How to customize a process template using TFS process editor

• Now that we have created the project in TFS with a specified process template. We can create and track the workitems as defined in the template. First let me give you an idea of how the workitems are defined in a process template. In other words – Workitem’s Anatomy: Structure and data of the workitem type are stored in the database of the Team Foundation Server. We can export and import it to an XML file using the command line utilities: WitImport, WitExport.  You can also use the process template editor for the same.

 There are three sections to it: 

• Fields
• Workflow
• Form

 Let’s look at the details of each one by one. This will help you create your own custom workitems.  

• Fields

We can also consider them as the workitem attributes (i.e. Data to be stored for each workitem). Each field has the following attributes: 

1. Name : Field name
2. Data type: Supported datatypes are like string, integer and double as well as some complex types as DateTime, PlainText, HTML, History and TreePath (to specify where in the area or iteration that workitem fits in)
3. RefName: A refname has to be a unique identifier for example MyCompany.StartTime. Qualifier names System and Microsoft are reserved. System qualifier is used for fields which store the data which are required to be present in every workitem type. Examples of System qualifier can be System.Name. Microsoft qualifier is used to qualify fields which are more specific to the workitem types, and are shipped with the default process templates.
4. Reportable:If the field is to be reported then we need to provide whether the field will be put in the OLAP cube as ‘dimension’, ‘measure’ or ‘detail’.

   1. Dimension – Use this for fields that have lists of valid values. Work Item Type and State are good examples of dimensions. The Dimension field can be used to filter reports.
   2. Detail – This option is a good choice for unrestricted text fields because it lets you use them in reports. However, any reports that you build using these fields must use the relational database instead of the cube.
   3. Measure – Measures are the numeric values in your reports. Each measure will appear in both the Current Work Item measure group and the Work Item History measure group. 

1. Rules:There are some predefined rules that you can associate with the fields. These rules are: REQUIRED, READONLY, FROZEN (as soon as a field has a value after a commit the value can no longer be modified.), EMPTY, CANNOTLOSEVALUE, NOTSAMEAS (with a refname of other field), VALIDUSER (with or without specific group name), AllowedValuesMatch (With a pattern), Prohibited values etc… The rules can also be applied conditionally by using the elements like: WHEN, WHENNOT, WHENCHANGED and WHENNOTCHANGED. Ex: <When field=”System.Name” value=”Jon”> means that apply the rule only if System.Name value is equal to ’Jon’ 

         

  Workflow

Each workitem is designed to go through a workflow and you can define that workflow using States and Transitions elements.    

• States – These are set of values that a workitem can have during its life cycle stages. Ex: Active, Complete etc…
• Transitions - transition of a work item from one state to other. Possible routes a workitem can take ex: - Active to Complete, Active to deferred etc… We have to provide one transition compulsorily. That transition is from nothing (denoted by “” as initial state) to any other state which we want should be the initial state of the workitem as soon as it is created.  Only the transitions that are defined in the workflow can happen. Every transition should have a reason for the transition associated with it. All the possible reasons should be defined in the definition of the transition. We may also give a default reason which may be used if the user does not explicitly select a reason while activating the transition.

 Transitions can be triggered in two ways:

a)     when the user decides to change the state of a workitem

b)     on a specific action: Say check-in  

Please observe the XML structure below to understand the details:

Reason:

<WORKFLOW>

<STATES>

<STATE value=”Created”>

<STATE value=”Closed” />

</STATES>

<TRANSITIONS>

<TRANSITION from=”" to=”Created”>

        <REASONS>

                <REASON value=”New”>

        <REASONS>

</TRANSITION>

<TRANSITION from=”Created” to=” Closed”>

        <REASONS>

                 <DEFAULTREASON value=”Deferred”/>

                 <REASON value=”No Plans to Fix”/>

        </REASONS>

</TRANSITION>

</TRANSITIONS>

</WORKFLOW>

Action:

<TRANSITION from=”Development” to =” Build”>

<ACTIONS>

<ACTION value=”microsoft.vsts.actions.checkin”/>

</ACTIONS>

</TRANSITION>