Skip to Content

Business: Build me an app.

Developer: Sure, cool.

Business: When can I have it by?

Developer: Um… well, how big is it?

Business: It’s just an app — it’s like … medium sized.

Developer: Oh. Medium. Of course. 6 weeks?

<6 weeks later>

Business: This was supposed to have 50 more features. What gives?

Developer: You said medium?

—-

 

What is an app?

Just because Fiori looks simple, doesn’t mean that it is simple to build. An app can take anywhere from 1 hour to 1 year to build depending on the number of features in it and the complexity.

or

The goal of this blog is to create a baseline for measurements intended for use in Agile / Scrum teams with relative sizing and story points.

 

By the way

These points won’t map exactly to hours. Developers are not all created equal. Super geeks can often produce at over 10 times the velocity of a junior developer, with 1/10th of the bugs. Hours estimates depend on the expertise of the team and the delivery complexity of the environment (i.e. an environment with 5 test phases takes more hours to deliver than one with 1 test phase).

 

Hint: Assess your scrum teams based on $/point, not $/hr.

 

Method

In order to establish a standard, we should agree on three things:

  1. Acceptance criteria (Definition of Done)
  2. Points description
  3. Technical debt

 

Acceptance Criteria

If one story is held to a much lower standard of quality than another it’s not really a useful comparison. Fiori is defined by style, simplicity, and great technology. The bare minimum acceptance criteria (aside from the business need) is:

 

Points Description

The size must reflect everything required to get the story to PSPI (potentially shippable product increment).

  • 1 – A simple change, like a new field or description
  • 2 – A small feature, like a new form, or set of fields
  • 3 – A bigger feature, typically including new logic and data sources
  • 5 – A large feature, including complex logic, a new page, and multiple data sources
  • 8 – A set of features, often times in a new app with a new framework
  • 13 – Typically broken down into changes and features, or reserved for very complex features.

 

Technical Debt

Technical debt is a critical component to calculating net velocity (points accepted / sprint – debt / sprint). To keep releases moving fast shortcuts must be taken to get products to end users and begin the feedback loop. Known bugs, temporary tables, shortcuts, and everything else that will need to be remediated later should be recorded as technical debt. The points scale should match the scale from above. These special stories should be recorded in the backlog just like new features. Hopefully you use a tool capable of categorizing things like this.

 

Examples

It’s hard to estimate points without a reference. Even with the descriptions above, with different teams and scrum masters, etc. there is varying interpretations. Here we will reference 3 public & popular applications from SAP that should align expectations. We may add some other types in the future.

 

Example 1: My Inbox Extension – [Extension / Workflow] – Approve Purchase Order (35 points)

Stories:

Story Size Comments
Procurement Manager needs a tile on Fiori Launchpad to launch My Inbox 2 If My Inbox is already in use, remove this story.
Procurement Manager needs to see a list of PO’s pending approval including ID, name, priority, and date. 5
Procurement Manager for approval must see details including ID, price, currency, status, Supplier, Created On, Net Order Value, Payment Terms, Incoterms, Incoterms (part 2), Company Code, Purchasing Group, and Purchasing Organization. 3
Procurement Manager for approval must see list of items in a PO including Short Text, Material Group, Material, Order Quantity, and Net Order Value. 5
Procurement Manager for approval must see attachments for the PO. 5
Procurement Manager for approval must see recent PO workflow history. 3
Procurement Manager must be able to Approve a PO. 3
Procurement Manager must be able to Reject a PO with reason 3
Procurement Manager must be able to Release a PO. 1 Reduced from 3->1 because all actions are similar grouping.
Procurement Manager must be able to Forward a PO. 1 Reduced from 3->1 because all actions are similar grouping.
Procurement Manager must be able to Suspend a PO. 1 Reduced from 3->1 because all actions are similar grouping.
Procurement Manager must be able to send a URL to the PO approval for sharing. 3

 

Example 2: My Leave Requests (Version 2) [Transactional] – (44 points)

Stories:

Story Size Comments
Employee needs a tile on Fiori Launchpad to launch Leave Requests 2
Employee needs to choose Leave requests of different types, such as Leave, Training, Sick, or Business Trips 5 List is system-defined and dynamic with appropriate rules.
Employee needs to be able to select start date, end date, start time, and end time and override the duration. 5 Can go back 3 months, and forward 12 months.
Employee needs to view current used and available time off on calendar view while requesting. 3
Employee needs to see on a calendar status of upcoming days including if they are working days, non-working, approved, pending, public holiday, rejected, today, and selected days. 5
Employee should be able to change approvers based on the approved list of approvers. 3 List must be system-generated. Assumes all logic is already defined in SAP.
Employee should be able to add free notes to a request. 3 Up to 128 characters.
Employee should be able to add attachments such as PDF’s and images to the request. 5 Assumes virus scan and attachment infrastructure already in place for Fiori.
Employee should be able to see a history of requests and status of those requests. 8
Employee should be able to see their entitled time off and corporate policies. 5

 

Example 3: Procurement Overview Page – [Overview Page] – (84 points)

Stories:

Story Size Comments
Purchaser needs a tile on Fiori Launchpad to launch Procurement Overview 2
Purchaser needs to be able to filter overview by Supplier. 2
Purchaser needs to be able to filter overview by Material. 2
Purchaser needs to be able to filter overview by Material Group. 2
Purchaser needs to be able to filter overview by Purchasing Category. 2
Purchaser needs to be able to filter overview by Purchasing Group. 2
Purchaser needs to be able to filter overview by Purchasing Organization. 2
Purchaser needs to see a card for Contract Monitoring with name, id, days, price, and % complete with chart sorted by consumption, valid-to-date,and target value. 8 Includes building data model.
Purchaser needs to see a card for Overdue Purchase Order Items with name, type, ID, days, quantity, and price sorted by overdue days and value. 8 Includes building data model.
Purchaser needs to see a card for Purchasing Spend Trend including a chart over the last three quarters. 8 Includes building data model.
Purchaser needs to see a card for Purchasing Spend by Material Group including the Material Group and spend on a chart. 8 Includes building data model.
Purchaser needs to see a card for Urgent Purchase Req Items – Unsourced including title, date, id, unit, and price. 8 Includes building data model.
Purchaser needs to see a card for Supplier Evaluation Trend including # of suppliers evaluated over the last 365 days. 8 Includes building data model.
Purchaser needs to see a card for Supplier Performance Monitoring including supplier score and spend with details of the top suppliers. 8 Includes building data model.
Purchaser needs to see a card for Non-Managed Spend by Supplier including supplier and spend with a chart 8 Includes building data model.
Purchaser needs Contract Monitoring card to drill into Contract Fiori App. 2 Does not include destination app, only link.
Purchaser needs Supplier Performance card to drill into Supplier Fiori App. 2 Does not include destination app, only link.
Purchaser needs Purchasing Spend by Material Group card to drill into details of Purchasing spend Fiori App. 2 Does not include destination app, only link.

 

What’s next?

I think everyone who is delivering in this mode-2 style could benefit by creating some standards around acceptance criteria and sizing. As digital transformation matures in the large enterprise, there will be a disruptive shift to delivery. Those organizations that can embrace this seismic shift will be the new leaders and will reap all of the rewards. What do you think?

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Matt Harding

    Hi Gavin,

    Excellent work, especially with the examples; and I do like the way you break up the work. So just wanted to say that and add the following random thoughts:

    1. Nearly all apps have a tendency to change during the design stages; and (even though it costs a lot more) after the initial build.  What I’d like to see customer embrace more is the ability to work on releases (or at least staged delivery) with stories that get completed; and really the initial quote look at the maximum type of effort with flexibility from all parties. The time of having a signed off spec and the customer holding a consultant to do exactly what the piece of paper says should be beyond us now (though I know it’s not for commercial reasons).
    2. With the state of Fiori development, there can be way more than 10x slower development, with 10x the bugs (not to mention reduced usability) – and this will hurt any quote once you get multiple developers on board. Not to say you shouldn’t do this; but I feel the standards behind development of Fiori apps (use of JSON, OData, field level and business logic error handling, draft handling, annotations, CDS, SADL/CDS, SADL/BOBF, fiori Elements, etc); we can all end up developing a completely different app.  Hopefully SAP address this with more advanced training, and maybe OData v4 fixes everything, but for now; the numbers above can be wildly different if you don’t do the actual lower level design. (just an issue generally that effects the ability to do the above with any accuracy between developers).
    3. Thinking Bimodal IT, the TDD approach is rarely costed into a project; especially the time required for developers who have not done it to learn how to do it; meaning…It doesn’t get done. Again, this probably comes into the customer working with the project team, understanding it will cost more up front, but will be more supportable, and easier to change in the future.

    Anyway, sounds like I’d like to work on one of your projects; as this type of approach really does need strong leadership to get in place (and hopefully you don’t need to be a big customer or on a big project to do this).

    Cheers,

    Matt

     

    (2) 
    1. Gavin Quinn Post author

      Hi Matt,

       

      Thanks so much for your thoughts. I’m glad this got you thinking.

       

      Regarding your points:

      1. Completely agree. A fixed size, cost, scope is difficult to achieve in practicality. With agile, what we try to do is use Design Thinking, and a story backlog like this, combine it with a predicted velocity for a given team size, and then try to hit MVP at about the 1/2 to 2/3 point of the project, leaving 2-3 sprints to work a new backlog. (procurement tends to be the biggest hurdle here).
      2.  Great points on the myriad options for development. This is where I hope to push a stronger UX COE, acceptance criteria, and provide more example applications.
      3. TDD is a tough sell for a project — you really need a program model for something like this to work.

      Working together — likewise & I appreciate the commentary!

      (1) 

Leave a Reply