CIOs Discuss Prioritizing Projects by Business Value

Mike HarrisLast week I had the pleasure of speaking at The CIO and IT Security Forum in Miami. I also spoke at a CIO Forum this past fall. At these events, my presentations are delivered to small groups of CIOs/CISOs intentionally to allow an interactive and intimate dialogue. That said, I had about 35 people split across two presentations last week. My goal for these presentations is to offer ideas for using software business value to prioritize development projects at the strategic and tactical levels, to provide practical examples, and, above all, to evangelize to try to get more companies doing this stuff – visualizing the business value of their software development efforts.

The attendees were very engaged in this topic. Most of their interest was focused on using cost of delay and weighted shortest job first approaches to prioritize projects. In the first session, the audience requested I go through the calculations in detail, so I incorporated that into the second presentation and again got a positive response. There was something of an “aha” moment in both sessions as they realized that coming up with relative business value for prioritization purposes is actually a practical proposition.

In the first session, we had a substantial group of CISOs, and we talked about where information security investments fit in the business value of software – a particular piece of software development could result in a reduction of risk, but all software development has the potential to add risk of a vulnerability if security is ignored or is simply paid lip service. 

Of the 35 or so participants, just two claimed to attempt to prioritize by business value. They were able to describe their approaches to the other participants. This is one of the great things about CIO Forum events – participants learn as much from their peers as they do from the presenters, and I always try to encourage this interchange during my sessions.

Do you prioritize your software development initiatives by business value? If not, what criteria do you use to prioritize your projects?  If you’d like to learn more about focusing on software business value to prioritize your efforts, click here for white papers, additional blogs, and webinars on the topic.


Mike Harris
CEO

 

Written by Michael D. Harris at 05:00

Can Function Points Be Counted/Estimated From User Stories?

Trusted Advisor

Introduction

Since the invention of function points (FPs) any time new development methods, techniques, or technologies are introduced the following questions always arise:

  • Can we still use FPs?
  • Do FPs apply?
  • How do we approach FP counting?

These questions came up around middleware, real-time systems, web applications, component-based
development, and object-oriented development, to name a few. With the increased use of Agile methodologies, and therefore the increased use of User Stories, these questions are being asked again.  It is good to ask these questions and have conversations to ensure that the use and application of FPs is consistent throughout the industry in all situations.  The short answers to the questions are:

  • Can we still use FPs? YES. 
  • Do FPs apply? YES. 
  • How do we approach FP counting? The answer to this last question is what this article will address.

Getting Started – Determine the Purpose and Scope

As with any FP count, it is important to identify the purpose of the count and to fully understand how the resulting data will be used.  This will ensure that the correct timing, scope, and approach is used for the FP count.  The following are examples of situations where FPs can be useful.

Purpose: High-level estimate to determine feasibility

If the purpose is to determine the feasibility of moving forward with the project or to complete a proposal, then typically a high-level estimate in a range is adequate. For this count the timing would be "now," and the scope would be whatever functionality is going to be developed. At this point in the life cycle not all information may be available, so some assumptions may need to be made. It is important to document these assumptions so that if the project progresses differently than planned it can be explained. For example, a User Story may state that "As a User I want to have a Dashboard showing application statistics."  It may be too soon to know the exact details, so an assumption of five average complexity External Outputs (EOs) may need to be made.  

Purpose: Estimate for Project Planning

Once a detailed plan is required, then more detailed estimates for effort and cost are necessary. For this purpose, the FP sizing should be completed at the start of the life cycle and updated at each major development stage. For Waterfall it could be at Requirements, Logical Design, and Physical Design phases. For Agile, the timing could be at Program Increment (PI) planning, or Sprint planning or both.  This purpose will require more accurate and thorough data, which requires a more detailed FP count, so more detailed User Stories are typically available. For example, the above Dashboard User Story may be broken down into 5 separate User Stories each describing a specific report: "As a User I want to be able to see a pie chart showing customer complaints by type."  In this case, each report can be examined to determine uniqueness and counted accordingly.

Purpose: Manage Change of Scope

Once a project is underway it is a good idea to track changes in scope to determine if the effort, cost, and schedule are going to be impacted by the change. These types of counts can be completed at different phases or at the time the scope change is identified. Once a change is sized using FPs, estimates can be developed to determine if the change should be incorporated into the current project and/or Sprint, or moved to another project and/or Sprint. A new User Story could be "As a User I want to be able to search customer complaints by type." In this case, a new report would be identified. If the User Story was "As a User, I want to be able to choose the color of customer complaint types in the pie chart;" this would be a change to the initial report we counted.

Purpose: Measure Quality and Productivity

If the purpose of the FP count is to support measuring the actual quality and productivity achieved for a project, PI, or Sprint, then typically User Stories wouldn’t be the source document of choice. This type of count is completed once functionality has been delivered, so ideally one would want to use the "live" system or user manuals to identify the actual functionality delivered to obtain the most accurate measurement. However, if access to the system isn’t available, User Stories may be the only source documentation available. Often documentation isn’t updated after the fact to show changes of what was and what wasn’t implemented so for this purpose it is important to confirm with development staff and/or users what was actually delivered along with referencing the User Stories. 

Utilizing User Stories for FP Counting – Overall Approach

Once the purpose and scope have been determined, the actual FP counting can begin. Applying the International Function Point User Group (IFPUG) rules is the same regardless of the purpose; however, the level of detail and the inclusion of functionality may be different depending on how the data will be used.

Conducting FP counts from User Stories is a bit easier than from other documentation since the majority of User Stories focus on the User perspective of "what" functionality is desired and not on "how" the functionality will be developed and delivered. Sometimes this perspective is difficult to find when looking at Designs or even the flow of physical screens. User Stories by their nature keep the FP analyst seeing things from the User perspective.

The IFPUG counting process starts with defining scope and boundaries and then moves on to identifying data functions and transaction functions. With a list of User Stories, it is more likely that all of this will be decided together as the count develops.

When counting from User Stories, the best approach is to just start walking through them one by one.  Oftentimes User Stories are grouped by categories (e.g. Order Entry, Validations, Reporting, Financials, etc.). If that is the case, it is best to focus on one category at a time. If it is early in the life cycle and the application boundaries are uncertain, it is best to take a first cut at counting the functions. Once the full scope of functionality is known boundaries can be determined and the FP count can be adjusted as necessary.

In following the IFPUG rules, it is important to count the logical functions. This can be difficult depending on the level of User Stories. It would be wonderful if everyone followed the same format and wrote User Stories the same way, but unfortunately that is not the case. One organization may have one high-level User Story for a project, while another organization may write multiple User Stories for the same functionality. One of the benefits of using FPs for sizing is that the method is consistent across all methodologies and isn’t impacted by how the documentation is completed. For example:

High Level – One User Story

  • As a User, I want to be able to enter, update, delete and view orders in the system to avoid manual paperwork.

Lower Level – Multiple User Stories

  • As a User, I want to be able to enter new orders in the system to stop paperwork.
  • As a User, I want to be able to edit orders previously entered in the system to stop paperwork.
  • As a User, I want to be able to delete orders previously entered to avoid incorrect orders be processed.
  • As a User, I want to be able to enter selection criteria to view orders previously entered in the system to stop searching paperwork.
  • As a User, I want the system to use entered selection criteria to display the correct orders to stop searching paperwork.
  • As a User, I want the system to validate the data entered into the fields when an order is added or updated to ensure accurate data is entered.
  • As a User, I want the system to validate the ordered product is "on hand" before accepting the order.

In the above examples, the FP count would be the same. When a User Story seems to be at a high level, it is important to break it down into all of the Elementary Processes (EP). When User Stories are written at a lower level, it is important to look at all of the similar stories together to potentially combine them into the EPs.

The result of the example above is as follows:

User Stories and Function Points

User Stories typically equate to the Transactional Functions (EIs, EOs, EQs); however, it is important for the FP Analyst to also keep Data Functions in mind while analyzing the User Stories. There may not be a list of tables or a data model available, so the FP Analyst may have to assume the ILFs based on the transaction functions.

If early in the life cycle assumptions may need to be made as documented above. Since the User Stories imply the project is automating a manual system then all functions would be new. That would mean that in order to edit or display orders previously entered, they would need to be stored somewhere; hence counting the ILF. 

If at all possible, the FP Analyst should meet with Subject Matter Experts (SMEs) who understand the User Stories to get a full understanding and/or answer any questions. In addition, the FP Analyst should reference existing systems that may be comparable or past counts that may be relevant. FP Analysts usually have knowledge of many types of systems. It is okay to bring that knowledge and experience to the FP count to help identify potential functionality. Of course, everything still should be validated by the SMEs. 

If SME involvement is not possible, or if things are still not clear, then any assumptions that are made need to be documented fully. This will ensure that the FP count can be explained and updated correctly as the project progresses. In the example above, the assumptions document how the complexity was determined (e.g. Product file used for validation on Create and Edit EIs; Data Element Type (DET) assumptions). In addition, any further questions are documented (e.g. Need to check for multiple order Types that could impact the Record Element Types (RETs) and thus functional complexity of the ILF – this may also impact the number of Transactional functions).

Agile Development - Additional FP Counting Considerations

Since User Stories are typically associated with Agile development, it is worth mentioning a few items to consider for the FP counting in terms of timing and inclusion.

FP counting can be completed at the Program Increment (PI) level and/or the Sprint level. The PI usually encompasses the final delivered functionality, so the FP counting is completed normally. For an estimate, the count can be completed at PI planning. For quality and productivity measures, the counting occurs at delivery of the PI. Counting Sprints is handled a little differently.

Sprints can also be counted for estimation/planning and at the end of the Sprint for productivity and quality measures.  However, the sum of the Sprints is often greater than the PI count. The level
at which the User Stories are written can be impacted by the time boxing of the Sprints. For example, an initial User Story may be, "As a User, I want to be able to create a new order." During Sprint planning, it may be determined that the entire function cannot be completed in one Sprint, so it may be changed to two User Stories:

  • As a User, I want to be able to enter general information when creating an order.
  • As a User, I want to be able to enter order details when creating an order.

In this case, the FP count of the Transaction would be as follows:

FP count of user stories

The Sprints cannot be added together to obtain the total FP count for the project. Counting at the Sprint level is usually for internal measures to ensure the PI goals will be attained. It can also point out inefficiencies in the development process. If too much "rework" is occurring, perhaps changes need to made in how the project is being planned and managed. The ultimate goal would be to complete an entire EP in one Sprint and only have to revisit it in a later Sprint if new requirements are discovered.

Conclusion

FPs are the best measure for "size" and can be used for all methodologies and technologies. FPs can be counted from any documentation or from just interviewing SMEs. The most efficient and accurate FP counting uses both supporting documentation and information from SMEs. User Stories are an excellent source of information for FP counting. User Stories represent the User perspective and are typically written in a way that describes the functionality required. So, “Can function points be counted/estimated from user stories?” Absolutely. “What level of granularity is required?” Any level can be used; however, as with any documentation used, the more detailed the User Story the more accurate the FP count.

Written by Default at 05:00
Categories :

Visualizing the Value Through Information Radiators and Business Dashboards

Information RadiatorIn the Agile world, the term information radiator is now commonly used as a term for a visual display showing the status of a project. According to Alistair Cockburn, who coined the term, “An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions."

These information radiators used in the IT world are very similar to the business dashboards that have become widely used by management and C-level executives on the business side.  Business dashboards offer “at-a-glance views of KPIs (key performance indicators) relevant to a particular objective or business process” (Wikipedia).  Just like the dashboard on your car, a business dashboard will quickly alert you if there is an issue and provide other key information to help you quickly understand the current status.

Information radiators and business dashboards have many similarities. They both are designed with a human’s need to visualize something in order to better understand it. They are both simple and easily understood at a glance. They provide up-to-date, valuable information on a project or process and enable anyone on the team, even external stakeholders such as the C-level, to gain a clear view of where a project or process stands and if there are any bottlenecks that need to be addressed. 

In the world of software development, where the C-level needs to be informed on a high level about a project, an information radiator can be a powerful way to simplify complex data and present it visually to executives who are very familiar with viewing business dashboards on a frequent basis in other parts of the organization. Leveraging these powerful visualization tools, any authorized individual within an organization can gain a better understanding of the business value of the software development project without in-depth, time-consuming reports or meetings.

Do you use information radiators, business dashboards, or another visual tool to manage your software development projects and demonstrate the value to the business?  If so, I’d be interested in hearing from you about what you see as the biggest benefit your organization gains from using visual tools. Do they help you get stronger buy-in from your internal customers?  Do they keep your IT team more on track?


Mike Harris
CEO

Written by Michael D. Harris at 05:00
Categories :

5000-1 Foxes in the Henhouse

Steve KitchingIn the past week, we have seen one of the most remarkable sporting achievements by an unlikely underdog here in the UK. Leicester City FC, of the English Premier League, won the league with two games to spare, beating illustrious teams such as Manchester United and Chelsea to the top.

This was a team with no stars; in fact, it barely escaped relegation a year before, which bookmakers made 5000-1 outsiders to win the title.

How did they do it? Some say it was the discovery and subsequent reburial of Richard III in Leicester Cathedral after his remains were found in a local carpark, bringing the team this run of good fortune.

The truth is that the victory was due to an incredible display of teamwork and commitment. There were no egos, just a drive to perform and support each other to consistently deliver results time after time.

Other teams failed, including my local side, Newcastle, where egos and attitudes ruled and so performances and results degraded.

Why am I talking about this on a software blog? We can all relate this situation to our experience of teamwork in the IT world. I’ve worked on teams where egos dominated. Whoever shouted the loudest would win, and inevitably the team would struggle to meet its goals. Compare this to teams who worked together harmoniously and delivered the goods time after time. The way a team works together directly affects the results.

This lesson can apply to any team in the IT space, but the mantra of teamwork should shine most predominantly in the Agile space, where the team(s) should pull together for a common goal.

How do you improve team culture and habits? We suggest the AgilityHealth Radar, which is a strategic retrospective that focuses on the top areas that affect team performance and health. With the results, there is a clear path forward to improved team culture and thus improved results.

So, are you a Leicester or something else entirely?


Steve Kitching
Estimation Specialist

Written by Steve Kitching at 05:00

A Customized Sizing Model

We work with a lot of clients, and they vary in size, industry, and location. They also, of course, vary in the reason they come to us for help. Sometimes they're in need of training, sometimes they're looking for help in one specific area, and sometimes they need help identifying what their actual problem even is. The common theme between all of our engagements is that our focus is on value: What value can we provide to our clients that will truly impact their organization, beyond even IT?

In a recent engagement, a business came to us with a problem. They were bidding on a Navy contract. The contract required the use of function points. Their experience with sizing was minimal. Could we help?

Yes.

But, we believed that the company needed more than just one simple size for the entire project. The value we provided was in leveraging our experience to build a customized, flexible sizing model to most effectively meet the needs of the client - and for less than the cost of our competitors.

Read the case study to find out more about the engagement.

Download.

 

 

 

Written by Default at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!