SAP Agile + Fiori: Proposing a sizing standard (with 3 samples)
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.
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.
In order to establish a standard, we should agree on three things:
- Acceptance criteria (Definition of Done)
- Points description
- Technical debt
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:
- Fiori Design Guidelines met
- Documentation created
- Tests passed (hopefully test driven development)
- Development best practices used
- Multiple language
- Live demo
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 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.
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)
|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)
|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)
|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.|
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?